tdd与非平凡的算法

Question

在这些日子里，我用Java编写了一些数据结构。他们中的许多人（如果不是全部）提供了一个非常简单的界面（添加，包含，删除），但在幕后有非平凡的算法。

在这种情况下如何使用tdd技术？

我认为问题在于tdd（通常是单元测试）是关于测试接口而不是实现。我对吗？我怎么处理这个？

如果你知道处理这种情况的任何技术，请告诉我。

感谢您的帮助。

Answer 1

你是正确的TDD是关于测试接口，而不是实现。 那说，你为什么要关心测试实际的实现？关键是如果你充分测试界面，实施无关紧要。

当您在实施中发现错误时，这意味着它违反了您向外部世界公开的界面。您需要将其追踪到违反界面的位置。这就是你编写测试用例的地方。

Answer 2

如果您的实施很复杂，那么在较小的模块中分解它是个好主意。这些较小的模块将具有自己的接口，您可以进行单元测试。例如，如果您通过深度优先搜索来解决数独，则需要单独开发深度优先搜索算法和数独位置枚举算法。我不久前在博客上写道：http://matteo.vaccari.name/blog/archives/416

Answer 3

测试界面远远优于测试实现。稍后，当您重构实现时，您的测试仍然有效。

如果您觉得您的方法太复杂而无法进行充分的单元测试，那么可能这表明您需要重构代码并将其分解为几个较小的（可能是私有的）方法，这些方法可以单独测试。

Answer 4

要测试某个实现是否包含某些限制（即：比较次数，性能等），您可以使用测试来TDD这些约束。

我发现这个Twitter对话非常有见地：http://twitoaster.com/kentbeck/brunopedroso-i-think-you-could-tdd-quicksort-youd-need-assertions-about-the-of-comparisons-ways-to-incrementally-improve-the-count/

它谈到了这个想法：TDDing快速排序。我们知道快速排序比冒泡排序更快。两种算法都会提供相同的输出（排序的集合），但它们具有不同的约束。

因此，您在测试中明确添加了算法的约束（显然，您需要测试您的算法是否按照您的预期执行）。

我同意在这个例子中你提到了一些你已经知道答案的东西。但是，如果您必须找到复杂的算法，那么您可能不会一直使用TDD。但测试和约束测试将帮助您了解您是否找到了答案。

Answer 5

我发现RSpec书中的TDD / BDD示例非常有用 - http://www.pragprog.com/titles/achbd/the-rspec-book这可能是导向导向的一些内容，但作者从书中定义问题，到识别简单的测试用例到复杂的案例以直观的方式。该书中的例子是关于开发游戏及其在通过所有测试方面的进展。

这也可能对您有用，因为您正在谈论接口，而BDD则是关于测试应用程序的行为（在您的案例算法中）。