问题标签 [tdd]

考虑这样的代码：

我想测试如果我用 3 个值填充向量，我的函数将以正确的顺序和数量调用。例如，我的测试可能如下所示：

你建议如何测试这个？有没有办法用 CppUnit 或 GoogleTest 框架来做到这一点？也许其他一些单元测试框架允许执行这样的测试？

我知道如果不从这些函数中调用任何调试函数，这可能是不可能的，但至少可以在某些测试框架中自动完成。我不喜欢扫描跟踪日志并检查它们的正确性。

UPD：我不仅尝试检查对象的状态，还尝试检查执行顺序以避免尽早出现性能问题（通常我想知道我的代码完全按照我的预期执行）。

最近，我在用 Python 开发 GUI 应用程序时一直在试验 TDD。我发现有测试来验证我的代码的功能是非常令人放心的，但是遵循一些 TDD 的推荐实践是很棘手的。也就是说，首先编写测试很困难。而且我发现很难让我的测试可读（由于大量使用模拟库）。

我选择了一个名为mocker的模拟库。我经常使用它，因为我正在测试的大部分代码都会调用（a）我的应用程序中依赖于系统状态的其他方法或（b）没有事件循环就无法存在的 ObjC/Cocoa 对象等。

无论如何，我有很多看起来像这样的测试：

请注意，这实际上是三个测试；都使用相同的参数化测试功能。这是正在测试的代码：

我在使用 mocker 时注意到的一件事是，首先编写应用程序代码然后再返回编写测试更容易，因为大多数时候我都在模拟许多方法调用和编写模拟的语法调用比应用程序代码更冗长（因此更难编写）。编写应用程序代码并以此为基础对测试代码进行建模会更容易。

我发现使用这种测试方法（以及一些纪律），我可以轻松编写具有 100% 测试覆盖率的代码。

我想知道这些测试是否是好的测试？当我最终发现编写好测试的秘诀时，我会后悔这样做吗？

我是否违反了 TDD 的核心原则，以至于我的测试是徒劳的？

我对 TDD 有复杂的感觉。虽然我相信测试，但我对测试驱动我的开发工作的想法有疑问。

当您编写代码以满足为满足您现在的需求的接口编写的一些测试时，您可能会将注意力从构建可维护的代码、简洁的设计和健全的架构转移。

我在驱动而不是测试方面遇到问题。有什么想法吗？

我刚开始进行 DI 和单元测试，遇到了一个障碍，我相信这对于那些更有经验的开发人员来说是不费吹灰之力的：

我有一个名为 MessageManager 的类，它接收数据并将其保存到数据库中。在同一个程序集（Visual Studio 中的项目）中，我创建了一个存储库接口，其中包含访问数据库所需的所有方法。该接口的具体实现在一个名为 DataAccess 的单独程序集中。

因此 DataAccess 需要对 MessageManager 的项目引用才能了解存储库接口。而MessageManager 需要对DataAccess 的项目引用，以便MessageManager 的客户端可以注入repository 接口的具体实现。这当然是不允许的

我可以将接口移动到数据访问程序集中，但我相信存储库接口应该与使用它的客户端位于同一个程序集中

那么我做错了什么？

有没有办法在 Java 中使用 JMock 来模拟对象构造？

例如，如果我有这样的方法：

...有没有办法在测试方法中模拟对象构造的期望？

我希望能够期望调用某些构造函数，而不是使用额外的代码来检查类型（因为它并不总是像我的示例那样复杂和简单）。

所以而不是：

我可以期望调用某个构造函数。只是为了让它更简洁一些，并以更易读的方式表达实际正在测试的内容。

请原谅这个简单的例子，我正在处理的实际问题有点复杂，但是有期望会简化它。

更多背景知识：

我有一个简单的工厂方法，它创建包装对象。被包装的对象可能需要在测试类中难以获得的参数（它是预先存在的代码），因此很难构造它们。

也许更接近我实际寻找的是：有没有一种方法可以一举模拟整个类（使用 CGLib），而无需指定要存根的每种方法？

所以 mock 被包装在一个构造函数中，所以显然可以在上面调用方法，JMock 是否能够动态地模拟出每个方法？

我的猜测是否定的，因为那会非常复杂。但是知道我在叫错树也很有价值:-)

在用 JavaScript 开发 UI 时，我很难找到正确遵循 TDD 原则的最佳方法。解决这个问题的最佳方法是什么？

是否最好将视觉与功能分开？您是否首先开发视觉元素，然后编写测试，然后编写功能代码？

我的一个朋友正在解释他们如何在他的工作场所使用 TDD 进行乒乓配对，他说他们采用“对抗性”方法。也就是说，当测试编写人员将键盘交给实施者时，实施者会尝试做最简单（有时是错误的事情）以使测试通过。

例如，如果他们正在测试 GetName() 方法并且测试检查“Sally”，则 GetName 方法的实现将是：

当然，这会（天真地）通过测试。

他解释说，这有助于消除检查特定固定值的幼稚测试，而不是测试组件的实际行为或预期状态。它还有助于推动创建更多测试并最终实现更好的设计和更少的错误。

听起来不错，但在与他的短暂对话中，通过一轮测试似乎比其他方式花费了更长的时间，我并不觉得获得了很多额外的价值。

您是否使用这种方法，如果是，您是否看到它得到了回报？

有谁知道在哪里可以找到单元测试指南和建议？我想要一些可以解决以下类型主题的东西（例如）：

• 测试是否应该与应用程序逻辑在同一个项目中？
• 我应该有测试类来反映我的逻辑类，还是应该只拥有我认为需要的那么多的测试类？
• 我应该如何命名我的测试类、方法和项目（如果它们在不同的项目中）
• 应该测试私有的、受保护的和内部的方法，还是只测试那些可公开访问的方法？
• 单元测试和集成测试应该分开吗？
• 是否有充分的理由不拥有 100% 的测试覆盖率？

我不是在问我应该是什么？

最好有在线资源。

如何对大型 MFC UI 应用程序进行单元测试？

我们有一些已经开发多年的大型 MFC 应用程序，我们使用一些标准的自动化 QA 工具来运行基本脚本来检查基础、文件打开等。这些由 QA 组在每日构建后运行。

但是我们想介绍一些程序，以便各个开发人员在将代码提交到日常构建之前，可以针对应用程序的对话框、菜单和其他可视元素构建和运行测试。

我听说过诸如仅在调试版本中出现的对话框上的隐藏测试按钮之类的技术，是否有任何标准工具包。

环境是 C++/C/FORTRAN、MSVC 2005、Intel FORTRAN 9.1、Windows XP/Vista x86 & x64。

• 假设我们意识到 TDD 的价值为时已晚。项目已经成熟，很多客户开始使用它。
• 假设使用的自动化测试主要是功能/系统测试，并且有大量的自动化 GUI 测试。
• 假设我们有新的功能请求和新的错误报告（！）。如此大的发展仍在继续。
• 请注意，已经有很多业务对象没有或很少进行单元测试。
• 它们之间有太多的协作/关系，这又只能通过更高级别的功能/系统测试来测试。本身没有集成测试。
• 具有大量表、视图等的大型数据库。仅仅为了实例化单个业务对象，就已经进行了大量的数据库往返。

我们如何在这个阶段引入 TDD？

嘲笑似乎是要走的路。但是我们在这里需要做的嘲笑似乎太多了。听起来需要为适用于现有东西（BO、数据库等）的模拟系统开发复杂的基础设施。

这是否意味着只有从头开始时 TDD 才是合适的方法？我很想知道在已经成熟的产品中引入 TDD 的可行策略。