前面我们学习I2C、USB、SD驱动时，有没有发现一个共性，就是在驱动开发时，每个驱动都分层三部分，由上到下分别是：
1、XXX 设备驱动
2、XXX 核心层
3、XXX 主机控制器驱动
      而需要我们编写的主要是设备驱动部分，主机控制器驱动部分也有少量编写，二者进行交互主要时由核心层提供的接口来实现；这样结构清晰，大大地有利于我们的驱动开发，这其中就是利用了Linux设备驱动开发中两个重要思想，下面来一一解析


一、设备驱动的分层思想
       在面向对象的程序设计中，可以为某一类相似的事物定义一个基类，而具体的事物可以继承这个基类中的函数。如果对于继承的这个事物而言，其某函数的实现与基类一致，那它就可以直接继承基类的函数；相反，它可以重载之。这种面向对象的设计思想极大地提高了代码的可重用能力，是对现实世界事物间关系的一种良好呈现。
      Linux内核完全由C语言和汇编语言写成，但是却频繁用到了面向对象的设计思想。在设备驱动方面，往往为同类的设备设计了一个框架，而框架中的核心层则实现了该设备通用的一些功能。同样的，如果具体的设备不想使用核心层的函数，它可以重载之。举个例子：
return_type core_funca(xxx_device * bottom_dev, param1_type param1, param1_type param2)
{
	if (bottom_dev->funca)
	return bottom_dev->funca(param1, param2);
	/* 核心层通用的funca代码 */
	...
}

     上述core_funca的实现中，会检查底层设备是否重载了funca()，如果重载了，就调用底层的代码，否则，直接使用通用层的。这样做的好处是，核心层的代码可以处理绝大多数该类设备的funca()对应的功能，只有少数特殊设备需要重新实现funca()。
再看一个例子：
return_type core_funca(xxx_device * bottom_dev, param1_type param1, param1_type param2)
{
	/*通用的步骤代码A */
	...
	bottom_dev->funca_ops1();
	/*通用的步骤代码B */
	...
	bottom_dev->funca_ops2();
	/*通用的步骤代码C */
	...
	bottom_dev->funca_ops3();
}

    上述代码假定为了实现funca()，对于同类设备而言，操作流程一致，都要经过“通用代码A、底层ops1、通用代码B、底层ops2、通用代码C、底层ops3”这几步，分层设计明显带来的好处是，对于通用代码A、B、C，具体的底层驱动不需要再实现，而仅仅只关心其底层的操作ops1、ops2、ops3。图1明确反映了设备驱动的核心层与具体设备驱动的关系，实际上，这种分层可能只有2层（图1的a），也可能是多层的（图1的b）。



       这样的分层化设计在Linux的input、RTC、MTD、I2 C、SPI、TTY、USB等诸多设备驱动类型中屡见不鲜。



二、主机驱动和外设驱动分离思想
主机、外设驱动分离的意义
       在Linux设备驱动框架的设计中，除了有分层设计实现以外，还有分隔的思想。举一个简单的例子，假设我们要通过SPI总线访问某外设，在这个访问过程中，要通过操作CPU XXX上的SPI控制器的寄存器来达到访问SPI外设YYY的目的，最简单的方法是：
return_type xxx_write_spi_yyy(...)
{
	xxx_write_spi_host_ctrl_reg(ctrl);
	xxx_ write_spi_host_data_reg(buf);
	while(!(xxx_spi_host_status_reg()&SPI_DATA_TRANSFER_DONE));
	...
}
     如果按照这种方式来设计驱动，结果是对于任何一个SPI外设来讲，它的驱动代码都是CPU相关的。也就是说，当然用在CPU XXX上的时候，它访问XXX的SPI主机控制寄存器，当用在XXX1的时候，它访问XXX1的SPI主机控制寄存器：
return_type xxx1_write_spi_yyy(...)
{
	xxx1_write_spi_host_ctrl_reg(ctrl);
	xxx1_ write_spi_host_data_reg(buf);
	while(!(xxx1_spi_host_status_reg()&SPI_DATA_TRANSFER_DONE));
	...
}
      这显然是不能接受的，因为这意味着外设YYY用在不同的CPU XXX和XXX1上的时候需要不同的驱动。那么，我们可以用如图的思想对主机控制器驱动和外设驱动进行分离。这样的结构是，外设a、b、c的驱动与主机控制器A、B、C的驱动不相关，主机控制器驱动不关心外设，而外设驱动也不关心主机，外设只是访问核心层的通用的API进行数据传输，主机和外设之间可以进行任意的组合。



      如果我们不进行上图的主机和外设分离，外设a、b、c和主机A、B、C进行组合的时候，需要9个不同的驱动。设想一共有m个主机控制器，n个外设，分离的结果是需要m+n个驱动，不分离则需要m*n个驱动。
      Linux SPI、I2C、USB、ASoC（ALSA SoC）等子系统都典型地利用了这种分离的设计思想。

最近学习了一本书《Python Web开发：测试驱动方法》，贯穿全书的便是测试驱动开发的编程思想。有点儿兵马未动，粮草先行的兵家思想。先简单总结一下这本书带给我的收获：1.学习了测试驱动开发的一种编程思想，与传统的瀑布开发流程又很大的出入。2.学习了如何写好功能测试，如何写好单元测试。3.先通过测试，再谈重构。

好，下面简单聊聊我对这种编程思想的体会。

何为测试驱动开发

维基百科中队测试驱动开发又一个比较正式的介绍：测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。

按照我个人的理解：将业务需求转化为功能测试及单元测试，业务代码则为了通过测试而不断的迭代。



测试驱动开发利弊权衡（由于未实战过tdd，看法可能略显稚嫩）

通过测试驱动开发，能保证业务代码能满足需求，不断的重构，能保证系统功能的正常运行。但是对于代码质量的把控，貌似很难做到。
测试驱动开发思想其实并不难理解，流程无非也是在测试开发重构过程中不断流转，但是个人感觉在工程实践上其实难度挺大
就个人工作经验来看，目前多数企业对于项目代码质量把控很差，项目周期紧，领导总是抱着先上线，遇到bug再解决，故TDD的开发模式在很多公司，尤其是创业公司中很难推广开，由于前期测试覆盖度不够，开发急促，导致后期上线维护异常困难
TDD的开发模式也应该分业务场景而看，但具体是哪些场景合适目前没有资格谈
TDD这种方式，还是得实践。然而以目前公司的平台，基本属于不可能。不过，就算不能在公司实践TDD的开发模式，它其中最重要的核心部分–测试，会让我在今后的开发过程中更加重视这部分。

敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程（Test-First Programming）。现在出现了（除了行为驱动开发以为，相关的还有像实例驱动开发（EDD-Example Driven Development），特性驱动开发（FDD-Feature Driven Development）等。

各种驱动开发之间的关系众说纷纭这里我们来聊一聊测试驱动开发（TDD）、验收测试驱动开发（ATDD）和行为驱动开发（BDD）。

测试驱动开发

Kent Beck最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，还专门撰写了《测试驱动开发》一书，详细说明如何实现。

测试驱动开发（TDD）使用自动化测试用例来指导开发代码。TDD 过程包含下列活动：

新增一个测试（成生测试用例并自动化），用于描述在代码内的某一小片段所期望的功能（程序设计的思路）；
	
此时因为相应的业务代码还没有编写，测试无法通过；
	
编写业务代码并运行测试直到测试通过；
	
在测试通过后，如果代码又有变更，例如对业务代码进行重构，则需再次运行测试以确保变更后的代码仍然可以通过测试；
	
对代码内的下一小片段继续执行上述过程，需要运行之前的测试（回归测试）以及新加入的测试。


行为驱动开发和测试驱动开发介绍: https://www.itsource.cn/web/news/1933.html

虽然“测试驱动开发”里面有测试的字眼，但是这个其实还是个开发活动，通常都不是由测试人员负责的，即使其中的驱动开发的测试的代码也不是测试人员编写的，至于里面涉及到的代码的重构这些内容，就更是开发人员而不是测试人员编写的。

狭义的测试驱动开发一般指的就是单元测试级别的测试驱动开发。但是广义的测试驱动开发不仅仅可以用于单元测试级别，还可以用于集成测试或者系统测试级别。当然也可以用于验收测试级别，此时就是后面要讲的验收测试驱动开发。

敏捷中很多思想都是建立在个人或者团队能力成熟度很高的基础上的。很多团队在实施测试驱动开发的时候无法顺利的进行下去，有很大一方面是实施的团队的技能还没有跟上。你很难想象一个开发团队，在单元测试都无法高质量的完成的情况下，转型采用TDD能够成功。

验收测试驱动开发

验收测试驱动开发（ATDD），在用户故事的创建阶段就定义验收准则及其相关的测试。ATDD 强调协作，各个利益相关者（开发、测试、业务代表等）不仅要理解软件组件应该有何种行为，还要理解如何做才能确保可以通过验收。

验收测试驱动开发是一种测试优先的方法。

首先需要再实施用户故事之前创建测试用例。测试用例由包括开发人员、测试人员和业务代表在内的敏捷团队创建，可以是手工测试用例也可以是自动化测试用例。第一步是开展一个由开发人员、测试人员和业务代表一起参与分析、讨论和撰写的规格说明研讨会。任何在用户故事中不完整、不清楚或者错误的地方都会在这个过程中得到修复。

下一步是创建测试。这一活动可以由团队一起完成或者由测试人员单独完成。在任何情况下，测试都应该由一个独立的个人（如业务代表）来确认。这里的测试是描述用户故事中特性的例子。这些例子会帮助团队正确地实施用户故事。由于例子和测试是相同的，二者经常可以互换使用。这项工作从基本的例子和开放的问题开始。

一般而言第一次测试都是正向测试，在没有意外或错误条件下确认正确的行为，比较执行的活动的顺序，判断是否如期望的那样进行。在正向路径测试完成后，团队应该撰写逆向测试并且覆盖非功能属性（如性能，易用性）。测试须以利益相关者都能理解的方式表述，包含以自然语言表达的语句，这些语句应该包括必要的前提条件以及任何可能的输入和相关输出。

例子必须覆盖所有用户故事的特性，并且不应该添加新内容到用户故事中。这意味，不应存在那些描述没有被写在用户故事中的例子。另外，不应该有两个例子描述用户故事中的相同特性。

行为驱动开发

行为驱动开发（BDD）使开发人员聚焦于测试软件行为是否符合预期。由于测试是以软件行为的形式展示出来的，测试对于团队成员和其他利益相关者来说更容易。单从BDD的概念来说，它不仅仅是针对测试，它使得在业务团队和开发之间达成共识。在软件项目中涉及多人紧密协作，由产品业务讲解功能需求，开发负责代码实现，测试保证软件质量，高质量的沟通对项目成功至关重要。如果在一个项目中业务人员用自己行话，开发人员用技术语言、技术思维去理解业务，在沟通过程难免出现分歧，开发人员就可能按自己的理解去实现了一个错误的功能。

BDD用通用自然语言描述实例（系统行为）。团队成员使用统一、易读的语言明确实例，作为验收测试标准。一方面可以消除理解上的歧义，一方面可以激发思考没有考虑到的场景。这里的实例是可以随时运行，反馈系统运行真实结果，如果运行失败，要么文档过时需要更新，要么系统出现问题需要修复。

在讨论BDD和TDD、ATDD的关系时，有些地方把BDD看成一个新的完整的开发流程，也有些地方把BDD看成是TDD的延伸，ATDD的一种落地的实例。这只是从不同的角度来看待BDD，并不影响BDD的本质。

典型的 BDD 框架将验收准则用 given/when/then 的格式表示：

Given（给定）某些初始上下文，

When（当）一个事件发生，

Then（则）确保某些输出。

 



 

行为驱动开发，让开发做正确的事: https://yq.aliyun.com/articles/594347

行为驱动开发（BDD） - 一个快速的描述和示例： https://www.cnblogs.com/Javi/p/7158573.html

五分钟让你彻底了解TDD、ATDD、BDD&RBE：https://mp.weixin.qq.com/s/KCrkL4NeuZeZvTu5Sc6B_g

小结

TDD、ATDD和BDD通过在开发之前清晰的描述系统行为和开发详细的测试用例来帮助开发人员更好的开发出高质量的代码。 测试从以前的破坏性的方法转换到建设性的方法中来。 给整个开发带来的新的思想上的变化。但是这些新的思想在实践过程中的具体能够带来多大的好处，也受到使用的组织和人的各方面条件的限制。没有一劳永逸的技术，只有持续不断的改进。这才是敏捷思想的内涵。

测试驱动开发
测试驱动开发基本思想是，开发人员先编写测试用例，再编写能通过用例的代码。就像砌砖师傅先用桩子拉上线再砌墙一样。
思想：
•       Test Driven
Development测试驱动开发
•       Acceptance TestDriven Development验收测试驱动开发
•       测试驱动设计，测试也是一项设计活动，编写用例的同时已在思考设计
•       持续集成，用例必须能自动化，且集成到CI环境中
优点：
•       提高代码行测试覆盖率
•       100%通过率，处理不通过的问题是优先级最高任务
•       快速变更的能力，变更后快速通过持续集成自动化测试
•       有信心重构，重构后的代码能快速测试
•       减少技术债，减少BUG泄露
敏捷转型过程中，测试驱动开发通常是最重要也最艰难的一个，只有实现快速自动化测试，才可能快速交付。前景非常诱人，但是在这个过程中我们的付出可能也是最多的。

按照敏捷思想，大部分的测试工作应该是开发来完成的，测试人员重点是保证开发测试的正确性，比如：测试方案、测试计划等。测试驱动开发的推广过程中，首要的问题是将开发人员长期以来形成的思维观念和意识形态转变过来，大部分开发人员只喜欢编码，不喜欢测试，更无法理解为什么没有产品代码的时候就先写单元测试；其次是相关的技术支持，测试驱动开发对开发人员提出了更高的要求，不仅要掌握测试和重构，还要懂得设计模式等设计方面的知识。
那么测试驱动开发跟持续集成如何关联到一起哪？简单总结一下：
•     Add atest
•     Addcode to pass the test
•     Passall existing tests
•     Cleanup the code
•     Checkin
•     ContinuousIntegration                        =
(   Auto Compile                                    
 +
Auto Build                                          
 +
Auto Deploy                                       
 +
Auto fullregression testing                
 +     
Check in codefrequently                    
 )