2

During a proposal about implementing unit tests for our projects, my manager argued that it could be more expensive to create unit tests since you will be maintaining two sets of code. His argument is whenever there is a change in requirement/functionality, the unit tests can be obsolete, hence the developers should update the tests in order to pass the automated build. He said that it can be inconvenient for the developers since their coding time might be reduced and spent fixing the tests.

The reason I wanted to implement unit tests is to minimize bug occurence especially the critical ones before the codes are turned to validation team for functional test. I also believe that the cost of creating unit tests can be recovered by having better quality systems.

Right now, his challenge to me is to create easy to maintain tests that would be easy to modify or if possible tests that will not break easily. I am using xUnit testing frameworks like JUnit and mocking frameworks like mockito and powermock to help in testing.

I'm looking for tips and techniques on how to write easy to maintain tests or how to avoid brittle test. Are there other tools which can come handy in creating such tests. I'm writing codes in Java and C++. Thanks.

4

5 回答 5

4

我认为您正面临文化差异-您的经理担心测试提供的潜在时间损失。众所周知的事实是，TDD/BDD 流程的前期成本更高 - 但随着时间的推移，您开始获得回报，因为“只改变这一孤立的事情......” - 不再引发痛苦/尴尬/代价高昂的错误。

我的建议是你做一些研究并整理一份文件，试图将这个过程出售给你的经理，根据你的业务中已经发生的事情提出一个商业案例，这个案例可以/应该通过一个可靠的测试套件来解决。

有一本书比我见过的任何网站、文章等都更适合 TDD。我强烈推荐任何想要练习 TDD/BDD/OOP 的人阅读它：http: //www.growth-object-orientated-software.com/（我没有从链接中赚取任何钱！-但它是我办公桌的绝佳补充！）。

于 2012-08-22T08:58:02.023 回答
2

根据我的经验，要真正说服“单元测试怀疑论者”几乎是不可能的。

我的建议：开始添加测试并增加对产品中最重要和经常变化的部分的选择范围。在你自己的时间做这件事，可能还有一个“同谋”，并为你的工作计时。

之后，向怀疑者展示这些测试发现的回归错误示例，以及您花费的时间实际上是值得的。如果您成功地做到了这一点，管理层将看到为单元测试投入资源的价值。

根据技术挑战，我同意这里的其他答案，熟能生巧，但有一些指导方针可以帮助你：

  • 每次测试只测试一件事。如果您有 100 个断言相同条件的测试，则当此条件发生变化时，您将不得不更新 100 个测试。
  • 如果您的“被测类”很大，其中包含大量逻辑，则很难对其进行测试。尝试将您的类重构为小的、连贯的逻辑单元。当这些单元之一发生变化时，破坏测试的数量将相对较少。
  • 测试您的公共接口，而不是实现细节。这将允许开发人员修复错误、提高性能和重构，而对测试的影响最小。

在Google 的“单元测试指南”的第一页还有更多 指南，您可以阅读The Art Of Unit Testing以获得关于编写良好单元测试的广泛报道。

祝你好运！

于 2012-08-22T18:24:34.507 回答
1

你是否编写单元测试不应该关心你的管理。通常重要的是功能可以快速实现并且没有错误。如何实现它取决于您，开发人员；单元测试只是一种方法。它最适用于松散耦合的代码，您可以轻松地模拟出依赖关系。

但是编写好的单元测试不仅仅是关于编写它们的决定，或者你使用的工具，它主要是关于你只能通过练习获得的经验。没有简单的方法可以让你编写好的单元测试，因为没有代码。如果你只是强迫没有经验的人编写单元测试，那么生产力肯定会下降，并且不会有明显的好处。最终，您应该编写单元测试，因为您相信它可以帮助您，而不是因为其他人认为它应该可以帮助您。

于 2012-08-22T02:22:14.920 回答
0

答案是单元测试应该测试实现而不是功能。因此，如果开发人员重构代码，单元测试不会发生任何变化，因为他们不是在测试内部，只是测试结果。

当然，如果你彻底改变界面或行为，测试当然会改变，但是你会想要测试新代码，所以你仍然会编写测试。

长话短说，有很多研究表明，从长远来看，一个好的测试套件可以大大节省时间。

于 2012-08-22T02:44:12.713 回答
0

如果被测系统发生变化，拥有统一的测试数据工厂可以降低维护成本。

测试通常具有相似的测试设置，只有很小的变化。

当我开始进行单元测试时，我使用复制和粘贴从现有的测试中创建新的测试。

每个测试都有一个很长的测试设置。

在测试系统发生更改后，我不得不更新许多测试。

今天我使用测试数据工厂，其中只分配了与标准的差异。

例子

  void customerUnder18ShouldNotbeGrantedAccess() {
      // Arrange
      Customer customer = TestdataFactory.CreateStandardCustomer();
      customer.setAge(16);

      // Act...
      // Assert ..
  }

这里有更多有用的提示。

于 2012-08-22T04:51:34.193 回答