如何进行测试驱动开发（TDD）

本文作者从个人的面试经历出发，讨论了在软件开发中测试驱动开发（TDD）的实际应用情况。作者指出，大多数公司并未正确实施TDD，原因通常是时间紧迫，认为编写测试代码是浪费时间。作者比喻不编写测试代码就像决定穿拖鞋去跑步，暗示这是一种短视的做法。

在实施单元测试的公司中，有些公司将单元测试用作类似协议测试，不隔离数据库访问，造成测试不具备可重复性。这种做法导致测试代码成为一次性废代码，甚至在持续集成环境中需要手动跳过单元测试，从而失去了单元测试的意义。

文章接着讨论了单元测试的正确做法。首先，单元测试应聚焦于业务逻辑，而与数据库或协议无关。数据库的正确性应由厂商保证，单元测试不应依赖数据库。其次，单元测试应尽量针对小的单元，例如业务用例中的特定功能，如果单元测试难以编写，可能是因为违反了单一职责原则。作者还强调测试代码质量的重要性，提倡测试代码应具有可读性、高聚合性，并遵循DRY（Don't Repeat Yourself）原则。

最后，作者建议为了测试业务用例，应使用Mock来模拟数据库访问接口，以实现100%的代码覆盖率。在Java中，可以结合Junit和Mockito来进行单元测试，并使用coverage工具检查代码覆盖率。文章还指出，在领域驱动设计（DDD）的开发中，由于业务领域和实体集中在Domain层，单元测试变得更加清晰和简单，有利于实现高效的TDD。