开始TDD – 挑战？ 解决scheme？ build议？

好吧，我知道现在已经有关于TDD入门的问题了。但是，我想我知道总体的共识就是这样做 ，但是我的头脑似乎还有以下问题：

• 在使用集合时，即使基于generics等，我们仍然“知道”它的工作方式，仍然会testing是否显示成功添加/删除/插入。
• 有些testing似乎需要永远的执行..比如在使用string输出的时候，是否有一种“更好”的方式来处理这种事情呢？ （例如，在parsing之前testing对象模型，将parsing分解成小操作并在那里testing）在我看来，你应该总是testing“最终结果”，但是这可能会变化很大并且很难设置。
• 我没有一个testing框架来使用（工作不会支付一个），所以我可以“实践”更多。 有没有免费的商业用途？ （此刻我正在使用良好的'ol Debug.Assert 🙂
• 可能是最大的..有时我不知道该怎么想不会发生..我的意思是，你得到你的绿灯，但我总是担心，我可能会错过一个testing..你挖深入尝试打破代码，或保持它，等待它所有后来（这将花费更多）。

所以基本上我在这里寻找的不是一个“ 只是做 ”，而是更多的“ 我做了这个，有这个问题，通过这个解决了他们 ”.. 个人经验:)

Answer 1

首先，当你第一次开始尝试在你的编码风格中使用TDD的时候感到沮丧是没问题的。 只是不要灰心，退出，你需要一些时间。 这是我们如何考虑解决代码问题的一个主要范式转变。 我喜欢从程序转换到面向对象的编程。

其次，我觉得testing驱动的开发首先是一个devise活动，通过创build一个testing，首先描述它将要公开的API以及如何使用它的function来充实组件的devise。 testing将有助于塑造和塑造被测系统，直到您能够封装足够的function以满足您正在进行的任何工作。

考虑到以上段落，我们来看看你的问题：

1. 如果我在被测系统中使用了一个集合，那么我将设置一个期望来确保调用代码来插入项目，然后声明集合的计数。 我不一定在我的内部列表上testingAdd方法。 我只是确保在调用添加项目的方法时调用它。 我通过在我的testing框架中添加一个模拟框架来完成这个工作。
2. testingstring作为输出可能是乏味的。 你无法解释每一个结果。 您只能根据被测系统的functiontesting您所期望的。 你应该总是把testing分解成它正在testing的最小的元素。 这意味着你将有很多的testing，但testing是小而快，只testing他们应该什么，没有别的。
3. 有很多开源testing框架可供select。 我不打算争论哪个是最好的。 find一个你喜欢的，并开始使用它。
   • MbUnit的
   • NUnit的
   • 的xUnit
4. 你所能做的就是设置你的testing来解释你想要发生的事情。 如果一个场景引入了一个function错误，至less你需要testing一下function，把这个场景添加到testing中，然后改变你的function，直到testing通过。 find我们可能错过testing的一种方法是使用代码覆盖 。

我在第一个问题的答案中向你介绍了这个嘲弄的术语。 当你在TDD中引入嘲讽的时候，它大大地使得testing更容易抽象出不属于被测系统的部分。 这里有一些关于嘲笑框架的资源：

• Moq ：开源
• RhinoMocks ：开源
• TypeMock ：商品
• NSubstitute ：开源

除了阅读这个过程之外，帮助使用TDD的一种方法是看人们这样做。 我build议看看JP Boodhoo在DNRTV上播放的电影 。 检查这些：

• Jean Paul Boodhoo关于testing驱动开发第1部分
• Jean Paul Boodhoo关于testing驱动开发第2部分
• Jean Paul Boodhoo揭秘devise模式第一部分
• Jean Paul Boodhoo揭秘devise模式第2部分
• Jean Paul Boodhoo揭秘devise模式第3部分
• Jean Paul Boodhoo揭秘devise模式第4部分
• Jean Paul Boodhoo揭秘devise模式第5部分

好的，这些将帮助您了解我所介绍的术语是如何使用的。 它还将引入另一个名为Resharper的工具，以及如何促进TDD过程。 在进行TDD时，我不能推荐这个工具。 似乎你正在学习这个过程，而你只是发现了一些使用其他工具已经解决的问题。

如果我没有通过添加Kent Beck 关于实用程序员的testing驱动开发的新系列来更新这个问题，我想我会对社区做一个不公正的事情。

Answer 2

从我自己的经验：

1. 只testing你自己的代码，而不是底层框架的代码。 所以如果你使用的是通用列表，那么就不需要testingAdd，Remove等

2. 没有2.看那边！ 猴子！

3. NUnit是要走的路。

4. 你绝对不能testing每一个结果。 我testing了我期望发生的事情，然后testing一些我期望得到exception或无效响应的边缘情况。 如果因为忘记testing而出现了错误，那么首先要做的事情就是编写一个testing来certificate这个错误存在。

Answer 3

我接下来是这样的：

• +1不testing框架代码，但是您可能仍然需要testing从框架类派生的类。
• 如果某些类/方法testing繁琐，可能会强烈地表明devise出了问题。 我尝试遵循“一级一责任，一办法一行动”的原则。 这样你就可以用更小的部分来testing复杂的方法。
• xUnit为+1。 对于Java，你也可以考虑TestNG 。
• TDD不是单一的事件，它是一个过程。 因此，不要试图从一开始就设想一切，但要确保在代码中发现的每个错误一旦被发现就被testing覆盖。

Answer 4

我认为最重要的事情（实际上是recursion的一个重要结果）TDD是依赖关系的成功pipe理。 您必须确保模块在隔离的情况下进行testing，无需精心设置。 例如，如果您正在testing最终发送电子邮件的组件，请将电子邮件发件人作为依赖项，以便您可以在testing中对其进行嘲弄。 这导致了第二点 – 嘲笑是你的朋友。 熟悉嘲笑框架和他们提倡的testing风格（行为，而不是基于经典状态）以及他们鼓励的deviseselect（ “告诉，不要问”的原则）。

Answer 5

我发现“ 三指标卡容易记住TDD本质”的原理是一个很好的指导。

无论如何，回答你的问题

1. 除非你写了，否则你不需要testing你“知道”的工作。 你没有写generics，微软呢;）
2. 如果你需要为你的testing做很多事情，也许你的对象/方法做得太多了。
3. 下载TestDriven.NET立即开始你的Visual Studio的unit testing，（除非它是一个Express版本）
4. 只要testing将会发生的正确的事情 。 您不需要testing所有可能出错的东西：您必须等待testing失败。

说真的，干嘛呢。 🙂

Answer 6

我不是TDD方面的专家，但以下是我的看法：

• 如果它是完全微不足道的（getter / setter等），不要testing它，除非你对代码没有信心。
• 如果这是一个相当简单，但不平凡的方法，testing它。 无论如何，testing可能很容易写入。
• 当谈到不期望发生的事情时，我想说如果某个潜在的问题是你正在testing的类的责任，那么你需要testing它是否正确地处理它。 如果这不是当前class级的责任，不要testing它。

xUnittesting框架通常可以自由使用，所以如果你是一个.Net人，请查看NUnit，如果Java是你的东西，请检查JUnit。

Answer 7

上面的build议是很好的，如果你想要一个免费的框架列表，你不得不比维基百科的xUnit框架列表更远。 希望这可以帮助 ：）

Answer 8

在我看来（你的里程可能会有所不同）：

1-如果你没有写它，不要testing它。 如果你写了它，你没有testing它，它不存在。

3-正如大家所说，xUnit的自由和伟大。

2＆4-确定要testing什么是你可以永远辩论的事情之一。 我试图用契约devise的原则来画这条线。 查看“面向对象的软件构造”或“实用程序员”了解详情。

Answer 9

保持简短的testing，“primefaces”。 在每个testing中testing最小的假设。 使每个TestMethod独立，为集成testing，我甚至为每个方法创build一个新的数据库。 如果您需要为每个testing构build一些数据，请使用“Init”方法。 使用模拟来隔离你的testing类与它的依赖关系。

我总是认为：“我需要写的最小代码量是多less，以certificate这一点对所有情况都适用？

Answer 10

在过去的一年里，我越来越确信TDD的好处。 我一路上学到的东西：1）dependency injection是你的朋友。 我不是在讨论控制容器和框架的反转来组装插件体系结构，只是将依赖关系传递给被测对象的构造函数。 这在您的代码的可testing性中回报了巨大的红利。 2）我以转换的热情/狂热着手，抓住了一个嘲弄的框架，开始使用模拟我所能做的一切。 这导致了脆弱的testing，需要很多痛苦的设置，并且一旦我开始任何重构就会崩溃。 使用正确的testingtypes。 假设你只需要尊重一个接口，存根将数据反馈给被测对象，只模拟你关心交互的地方。 3）testing应该很小。 目的是在每个testing中testing一个断言或交互。 我试图做到这一点，主要是我在那里。 这是关于testing代码的健壮性以及testing复杂性的时候，当您需要稍后重新访问时。

我在TDD方面遇到的最大问题是使用了标准化组织的规范和该标准的第三方实施，这是事实上的标准。 我把很多非常好的unit testing编写到规范的信件中，结果发现围栏另一侧的实现看起来更像是一个咨询文档。 他们玩得相当宽松。 解决这个问题的唯一方法是testing实现以及unit testing，并根据需要重构testing和代码。 真正的问题是我相信，只要我有代码和unit testing都是好的。 不是这样。 在进行unit testing的同时，您需要构build实际的输出和执行functiontesting。 整个过程中的小部分好处 – 进入用户或利益相关者手中。

Answer 11

除此之外，我想我会说我已经把我的想法放在了开始testing（在这个讨论和我自己的研究之后）的博客文章上，因为这对于查看这个线程的人可能是有用的。

“ TDD – testing驱动开发入门 ” – 到目前为止，我已经收到了一些很好的反馈，并且非常感谢你们提供的东西。

我希望这有帮助！ 🙂