本文转载自微信公众号《狗狗的前端世界》，作者西岭。转载本文请联系Gogo前端世界公众号。TDD原则独立测试不同代码的测试应该相互独立。一个类对应一个测试类（对于C代码或C++全局函数，一个文件对应一个测试文件），一个函数对应一个测试函数。用例也应该是独立的。每个用例不能使用其他用例的结果数据，结果也不能依赖于用例执行的顺序。一个角色：开发过程包括多项任务，比如：编写测试代码、编写生产代码、代码重构等。在做不同的工作时，专注于当前的角色，不要过多考虑其他方面的细节。测试单代码中的功能点可能很多，需求可能一个接一个出现。当你在任何阶段要添加功能时，都应该将相关的功能点添加到测试列表中，然后继续手头的工作，避免遗漏。测试驱动就是用测试来驱动开发，这是TDD的核心。实现某个功能，写某个类或某个功能，首先要写测试代码，明确如何使用和测试这个类和功能，然后再进行设计和编码。先写断言在写测试代码时，应该先写判断代码功能的断言语句，再写必要的辅助语句。可测试性产品代码设计和开发应尽可能提高可测试性。每个代码单元的功能应该比较简单，“大家自己扫门”，每个类每个函数只做该做的，不要搞成大杂烩。尤其是在增加新功能的时候，不要为了方便，就在原来的代码上增加功能。对于C++编程，您应该考虑使用OO方法，例如子类、继承和重载。及时重构对于结构不合理、重复等“有味道”的代码，在通过测试后，要及时重构。小步骤软件开发是一项非常复杂的工作，小步骤是降低复杂性的好方法。TDD的优点保证代码质量，因为先写测试，所以提前发现可能的问题；促进了开发人员的思维，有利于程序的模块设计；测试覆盖率高，因为代码是后写的，所以测试用例基本上都可以搞定；TDD的缺点增加了代码量，大多数情况下测试代码是功能代码的两倍或更多；业务耦合度高，在测试用例中使用了业务中的一些模拟数据，当业务代码发生变化时，重新组织测试用例；焦点过于独立，因为单元测试只关注本单元的健康，不能保证多个单元组成的整体是否正常；个人理解在前端应用的实际开发过程中，TDD更适合开发纯Function库，比如Lodash、Vue、React等。BDDTDD最大的问题是开发者最终做出来的可能会偏离实际功能需求。为了解决这个问题，有人发明了BDD。BDD（Behavior-drivendevelopment）是从测试驱动开发扩展而来的敏捷软件开发技术。BDD解决的另一个关键问题是如何定义TDD或单元测试过程的细节。一些糟糕的单元测试的一个常见问题是过于依赖被测函数的实现逻辑。这通常意味着如果要修改实现逻辑，即使输入输出没有变化，通常也需要更新测试代码。这就产生了一个问题，即开发人员对维护测试代码感到乏味和厌烦。BDD的核心目的是解决TDD模式下开发与实际功能需求不一致的问题。BDD不需要针对实现细节设计测试，而是针对行为进行测试。它从产品的角度出发，鼓励开发人员和非开发人员（产品、QA、客户等）之间的协作。由于BDD的核心是专注于软件的功能测试，所以BDD更多的是结合集成测试，是一个黑盒。BDD开发流程1.开发人员和非开发人员一起讨论并确认需求。2.自动化建立需求，确认是否一致。3.最后，实现每个文档示例中描述的行为，并从自动化测试开始，指导代码的开发。这样做可以使每个更改都变小并快速迭代，每次需要更多信息时将其向上移动。每次自动化和实施新示例时，您都会为系统添加一些有价值的东西，并准备好响应反馈。最流行的理想BDD解决方案是Cucumber。其协作流程如下：1.开发人员与产品、测试人员、客户等进行需求沟通和确认。2.使用统一的Gherkin语法将功能需求转化为需求文档。以描述性自然语言定义的测试，客户、测试人员和开发人员可以理解并达成共识。这种语法叫做GherkinSyntax，GherkinSyntax。使用关键字Scenario、Feature等描述场景使用关键字Given、When、Then描述步骤Feature：添加任务Scenario：在输入框中输入任务名称回车确认，输出到任务列表给定“HelloWorld”，当在输入框中回车时，然后在任务列表中添加一个名为“HelloWorld”的任务场景：在输入框中输入空内容，没有输出到任务列表中给定""，当在输入框中回车时然后任务列表不添加任何东西，Cucumber使用Gherkin语法读取纯文本描述的可执行规范，并验证软件是否按照这些规范执行。该规范包含几个示例或场景。每个场景都是Cucumber要执行的步骤列表。Cucumber验证软件是否符合规范，并生成一份报告，指出每种情况下的成功或失败。3、开发人员根据Gherkin编写测试用例4、编写代码使测试通过5、对新功能重复上述步骤BDD专注于产品功能，可能无法保证良好的代码质量和测试覆盖率，因此有人提出了一个解决方案是BDD+TDD。BDD-需求分析-描述需求定义文档-编写集成测试用例TDD-编写单元测试用例-编写代码使单元测试通过-重构优化编写代码使集成测试通过添加功能重复以上步骤个人理解也可以视为BDD是在需求和TDD之间架起一座桥梁。它将进一步将需求上下文化，更具体地描述系统应该满足哪些行为和场景，使TDD的输入更加优雅和可靠。还有一种基于集成测试的更轻量级的BDD解决方案。需求分析，编写集成测试用例，运行测试代码，通过重构优化使测试增加功能。重复BDD的上述步骤的好处：因为它注重所需功能的完备性，可以让开发者对程序更有信心。因为只关注功能，不关注实现细节，有利于测试代码和实际代码的解耦。由于大部分是写集成测试，所以开发效率比TDD好。BDD的缺点：因为主要是功能集成测试，所以不太关注每个功能，测试覆盖率比较低。TDDvs.BDD并没有严格保证代码质量。个人推荐：推荐使用TDD开发功能函数库。推荐使用BDD开发业务系统。俗话说，人生如旅途，不在乎目的地。虽然这在生活中可能是正确的，但在开发应用程序时却恰恰相反，您可以选择单独使用这些方法中的一种或将它们组合使用以获得更好的结果。编写测试的方式并不重要，只要编写省时且有价值的测试即可。前端自动化测试的权衡当我们开始编写自动化测试时，我们可能想要测试所有内容。每个实体开发人员都可能经历过未经测试的应用程序的痛苦，但在测试过程中，我很快学到了另一个教训——测试会减慢开发速度。编写测试时，牢记编写测试的目的很重要。通常，测试的目的是为了节省时间。如果你正在做的项目是稳定的，并且会长期开发，那么测试就可以带来回报。但是，如果测试的编写和维护时间比它们保存的时间长，那么您根本不应该编写测试。当然，很难知道在编写代码之前通过测试可以节省多少时间。但是，如果您正在为一个短期项目制作原型，或者在初创公司迭代一个想法，您可能无法从编写测试中获益。任何事情都有两个方面，软件测试不是灵丹妙药。虽然好处显而易见，但并不是所有的项目都值得引入测试框架。毕竟维护测试用例也是需要成本的。对于一些需求变化频繁，复用性不高的内容，比如活动页面，让开发人力去写测试用例，实在是得不偿失。大概有几个合适的测试场景：需要长期维护的项目。他们需要测试来确保代码的可维护性和功能稳定性。一个更稳定的项目，或者一个项目中更稳定的部分。为其编写测试用例，维护成本低。被多次复用的部分，比如一些常用的组件、库函数等。因为多次重复使用，保证质量就显得尤为重要。测试确实给我们带来了可观的收益，但不是立竿见影的。测试就像保险。如果您的健康状况良好，您可能几十年都不需要它。测试也是一样的，写完了就可以放心购买了，这是对代码的一种保证，如果有bug，可以尽快测试出来，没有bug最好，但是你不能说“写了那么多测试，结果查不出bug，浪费时间”。
