问题标签 [tdd]

真正TDD的好处是应用程序的实际测试，还是编写可测试的应用程序带来的好处？我问是因为我觉得谈话经常围绕着测试，而不是总的福利包。

我正在尝试测试一个简单的基于 WebForms (asp.net) 的 UI，并遵循 MVP 模式以使我的 UI 更具可测试性。

当我遵循后端算法的 TDD 方法时，我发现有一些单元测试重构是本着 DRY 原则（不要重复自己）的精神发生的。当我尝试使用 Rhino Mocks 将其应用于 UI 以验证我的交互时，在设置视图或模型期望时，我在 Controller 测试中看到了许多共性。

我的问题是：如果有的话，你通常会在多大程度上进行这种重构？我很想知道其他 TDDer 如何测试他们基于 MVC/MVP 的 UI。

我敢肯定，你们中的大多数人都在编写大量自动化测试，并且在单元测试时也遇到了一些常见的陷阱。

我的问题是您是否遵循任何编写测试的行为规则以避免将来出现问题？更具体地说：好的单元测试的属性是什么，或者你如何编写测试？

鼓励语言无关的建议。

当您仅使用数据访问层或大多数应用程序堆栈进行集成测试时。如果多个测试在同一个数据库上运行，那么防止多个测试相互冲突的最佳方法是什么？

使用 C#，我需要一个名为的类User，它具有用户名、密码、活动标志、名字、姓氏、全名等。

应该有方法来验证和保存用户。我只是为这些方法编写一个测试吗？我什至需要担心测试这些属性，因为它们是.Net 的 getter 和 setter？

采用测试驱动设计会失去什么？

只列出否定的；不要以否定的形式列出福利。

我完全赞同 TDD、重构和模式背后的想法，但是这些想法似乎确实存在巨大的差距，主要是它们非常适合 1 人的开发团队，但是当你开始重构代码时，10 人是处理您的工作时，您开始在各处遇到合并冲突，并且大多数 diff/merge 软件无法判断您将函数重构为自己的类。

你如何通过重构来清理你的代码，而不会给团队中的每个人带来严重的麻烦？

我想用 C#、Java 和 AS3 编写一个简单的颜色管理框架。我只想编写一次单元测试，而不是在 JUnit、FlexUnit 和 NUnit 中重新创建单元测试。

我想到了一个 xml 文件的想法，该文件通过设置、拆卸和一组测试定义了基于“实例”状态的“实例”和断言的操作。然后有一个实用程序可以将该 XML 转换为 xUnit 代码，用于任意数量的 xUnit。不过，在我开始浪费时间开发这样的解决方案之前，我想确保不存在类似的解决方案。

阅读对这个问题的回复测试驱动开发的缺点？我的印象是对什么是 TDD 以及应该如何进行有很多误解。在这里解决这些问题可能会被证明是有用的。

我是 RhinoMocks 的新手，除了在幕后发生的事情之外，我还试图掌握语法。

我有一个用户对象，我们称它为 User，它有一个名为 IsAdministrator 的属性。IsAdministrator 的值通过另一个检查用户安全权限的类进行评估，并根据这些权限返回真或假。我试图模拟这个 User 类，并伪造 IsAdministrator 的返回值以隔离一些单元测试。

到目前为止，这就是我正在做的事情：

现在，我期待 Rhino 会“伪造”对属性 getter 的调用，然后对我返回 true。这是不正确的吗？目前，由于 IsAdministrator 属性中的依赖关系，我遇到了异常。

有人可以解释我如何在这里实现我的目标吗？