请原谅我起这么一个标题来引人注意，之所以这么说，是因为我觉得通过这种方式调试代码还不够好，试想，在很多地方写
console.log是不是比较麻烦，而且调试完了之后还要把打印的代码删除，那么我们完全可以以另外一种方式来实现效果，既可以调试代码，又方便我们开发。
下面我将会为大家介绍一种优雅的开发模式，相信读者也有所耳闻，那就是 TDD 开发模式 。
TDD
什么是 TDD
TDD（Test Driven Development）测试驱动开发 ，这是一种非常好用的开发模式，它的核心思想是 先写好测试代码 ，再写业务代码 ，确保业务代码都能 100% 测试正确，当所有测试用例都通过后，业务代码也就写完了。
为什么使用 TDD
- 确保开发的功能一定能满足需求
我们开发软件大部分是因为用户需求，但在实际的软件开发过程中，我们可能会受到自己主观判断等等因素的影响，导致软件的开发方向发生偏离。没有开发出满足用户的需求，开发者自己又没有发现，往往只能在测试阶段才被挖出，这时就得继续开发了，很明显，这是不好的。
但 TDD 开发模式在一开始就将漏掉的需求写进测试了，那么在开发的时候一测试，就能立马知道哪里没开发好，好处显而易见了。
- 保证项目质量
TDD 要求测试先于开发，那么我们在开发时就势必要以测试为基准，做到所有测试能够百分百通过，那么最后项目运行时，可以肯定的是功能点的实现是没问题的。除此之外，开发人员能够根据测试结果不断调试功能模块、优化设计、重构代码，使其满足所有测试场景，从而提高了项目质量。
- 定位报错位置
使用这种模式的话，开发者首先需要对业务代码的功能点有十分清晰的认知，在此基础上完善测试代码，只要测试写得好，之后在写业务代码时，就能立刻定位问题所在，十分优雅。
- 测试用例即文档
TDD 过程中编写的测试用例，肯定是符合需求的，并且测试代码其实并不复杂，其中包含了所有的 case ，我们可以从中获取到的信息有 API 接口参数、响应的数据、适用的场景等等。通常我们想了解的东西都能从测试代码获取。
TDD 的实施过程
- 为功能添加测试；
- 编写业务代码；
- 测试；
- 重构业务代码；
- 继续测试；
- 不断重复
2和3，直到测试成功率为100%。
适用场景
- 写纯函数场景
对于那些能确定输入输出的函数，写测试用例能快速帮我们验证业务实现是否正确，而不用频繁地 console.log。
- 修 Bug 场景
这对没有任何测试的项目非常实用。当遇到 Bug 时，先写一个测试用例来复现问题，然后通过这个用例来调试业务代码。用例通过后， 业务代码也自然被修复了。
- UI 交互场景
用测试模拟真实用户的使用路径，然后再实现业务逻辑。 当测试用例通过后，说明需求的主逻辑也是能走通的。
后话
我知道，一定会有读者说到成本问题，因为开发业务已经很累了，还要花额外的大量时间去写测试，比如一百行的业务代码要写八百行的测试代码，这“亏本买卖”谁愿意做。我觉得关于这一点，因人而异吧，如果让你不限时地开发一个项目，并以做好该项目为首要任务，你会选择 TDD 或 BDD 开发模式吗，我觉得大部分人的答案可能是肯定的（可能有更好的开发流程？那当我没说吧~），因为这两种开发模式确实是值得肯定的，它们带来的好处会让开发者的付出是值得的，我们无非是收到客观环境的影响，才没有考虑使用这两者开发模式。对于初学者来说，这更是值得学习并实践的，因为这能培养我们的开发思维，十分有助于成长。
成本问题就说到这吧，毕竟现实很骨感，你觉得想试试的话就用，觉得麻烦的话就简单了解一下即可了。
