我试图理解TDD。假设我要为一个小项目编写多个测试类以及数十种方法。将有数百种测试类和方法组合起作用。是否有关于应该有哪些测试类的最佳实践，标准或指导？同样，每个类的任何方法？
我参与了Web应用程序开发的整个生命周期。有关书籍或培训的任何建议吗？提前谢谢！
答案 0 :(得分：1)
在TDD中，您没有“计划”编写数百种测试类组合。你所做的就是满足你的一个要求（通常只是要求的一小部分），并编写一个证明它已被满足的测试。您的测试将失败，因为您的代码尚未执行此操作。接下来，您编写一些代码，足以通过测试。然后你重构你刚才编写的代码 - 这个重构的目标是删除重复，遵循良好的OO设计原则，并使代码适合您的应用程序架构。
你会发现你会考虑不同的编码。你不要提前计划每个班级。您不会生成巨大的UML图表。相反，您需要增加产品以满足越来越多的需求。满足所有要求后，代码就完成了。
了解更具体的问题，我们所做的是在测试类和生产类之间建立一对一的关系。我喜欢通过将_Test后缀为类名来命名测试类：ShippingClass的测试成为ShippingClass_Test。这使得一个类的测试很容易找到。在ShippingClass_Test内部，ShipClass的每个方法都有几种测试方法。每种测试方法通过生产方法执行不同的流程。假设有一个CalculateShippingFees（）方法，这个要求必须处理税收，免税和国际运输。需求的每个部分都将驱动一个新的逻辑，这将导致另一个测试。我可能会编写一个CalculateShippingFees_TaxExempt_Test，CalculateShippingFees_Taxable_Test和一个CalculateShippingFees_TaxServiceOffline_Test（总是为您的错误处理路径编写测试。）
但是当我进入CalculateShippingFees_International_Test时，由于我正在重构，我意识到目的地比我想象的多，并且方法变得太大了。所以也许我使用策略模式将目标提取到一个新类中，然后我开始为每个目标编写测试。或许我发现我们的运输提供商有一个我可以利用的费用计算器，所以我更改代码以使用它。进行这些更改既快捷又简单，因为我知道只要我的所有测试都通过，我就可以改变我想要的任何内容！
这就是TDD的重点：您可以根据需要改进软件以满足您的需求。如果我建立了一个巨大的心理模型，说“我需要一个运费税级，一个国际目的地，一个国内目的地，一个海关费用计算器，等等等等”，我可能会花很多时间来建造这些课程只是为了以后发现航运提供商有一个API，免费提供给我所有的东西，我浪费了我的时间写它。或许我搞砸了最初的设计，认为海关费用是航运的一部分，而不是国际目的地的一部分。使用TDD，当我添加新的方法和类时，我将它们放在需要它们的地方。
关于这个主题有几本好书。像@Franck一样，我也推荐Mezaros'xUnit Test Patterns。 Roy Osherove有一本非常好的书The Art of Unit Testing。弗里曼和普赖斯有Growing Object Oriented Software Guided By Tests。 Kent Beck的书，Test Driven Development by Example是一种火花，很容易理解，但它已经老了，TDD的实践已经过去了。
答案 1 :(得分：0)
我想如果你开始编写你的代码会更好，你会告诉我们你认为你会有多少组合，推荐的书籍真的很棒，你也必须利用单元测试框架是什么你使用，junit（Java）支持那些组合的参数，Spock（groovy）使用非常棒的参数表