单元测试采用 [英] Unit test adoption
问题描述
我们已尝试在当前项目中引入单元测试，但它似乎不起作用.额外的代码似乎已经成为维护方面的难题，因为当我们的内部框架发生变化时，我们必须四处走动并修复任何挂起它的单元测试.
We have tried to introduce unit testing to our current project but it doesn't seem to be working. The extra code seems to have become a maintenance headache as when our internal Framework changes we have to go around and fix any unit tests that hang off it.
我们有一个抽象基类用于对我们的控制器进行单元测试，它充当调用子类的抽象方法实现的模板，即框架调用 Initialize，因此我们的控制器类都有自己的 Initialize 方法.
We have an abstract base class for unit testing our controllers that acts as a template calling into the child classes' abstract method implementations i.e. Framework calls Initialize so our controller classes all have their own Initialize method.
我曾经是单元测试的倡导者，但它似乎不适用于我们当前的项目.
I used to be an advocate of unit testing but it doesn't seem to be working on our current project.
谁能帮助确定问题以及我们如何让单元测试为我们工作而不是对我们不利?
Can anyone help identify the problem and how we can make unit tests work for us rather than against us?
推荐答案
提示:
避免编写程序代码
如果测试是针对严重依赖全局状态或位于丑陋方法主体中的过程式代码编写的，则测试可能难以维护.如果您使用 OO 语言编写代码，请使用 OO构造有效地减少这种情况.
- 尽可能避免使用全局状态.
- 避免静态，因为它们往往会波及您的代码库，并最终导致不应该是静态的东西.它们还会使您的测试上下文膨胀(见下文).
- 有效利用多态性来防止 过多的 if 和标志
代码中的阻塞点比其他部分更频繁地更改.在您的代码库中执行此操作，您的测试将变得更加健康.
There are choke points in code that change a lot more frequently than other pieces. Do this in your codebase and your tests will become more healthy.
- 良好的封装会带来良好的松散耦合设计.
- 重构和模块化.
- 保持测试规模小而专注.
尽你所能缩小测试和执行它们的环境.
Do whatever you can to shrink tests and the surrounding context in which they are executed.
- 使用组合方法重构来测试更小的代码块.
- 您使用的是较新的测试框架，例如 TestNG 或 JUnit4?它们允许您通过在测试生命周期中提供更细粒度的挂钩来消除测试中的重复.
- 调查使用测试替身(模拟、伪造、存根)来减少测试上下文的大小.
- 研究 Test Data Builder 模式.
您可能无法删除所有重复项，但仍尝试将其删除导致疼痛的地方.确保你没有删除太多的重复，以至于有人无法一目了然地告诉测试做了什么.(请参阅 Paul Wheaton 的 "Evil Unit Tests" 文章，了解对相同内容的另一种解释概念.)
You probably won't be able to remove all duplication, but still try to remove it where it's causing pain. Make sure you don't remove so much duplication that someone can't come in and tell what the test does at a glance. (See Paul Wheaton's "Evil Unit Tests" article for an alternative explanation of the same concept.)
- 如果无法弄清楚它在做什么，没有人会想要修复测试.
- 遵循 Arrange、Act、Assert 模式.
- 每个测试只使用一个断言.
想想记录和回放 Selenium 测试所涉及的复杂性，以及与测试单一方法相比，你会发生什么变化.
Think about the complexity involved in a record-and-playback Selenium test and what could change under you versus testing a single method.
- 将依赖项相互隔离.
- 使用依赖注入/控制反转.
- 使用测试替身来初始化对象以进行测试，并确保您正在单独测试单个代码单元.
- 确保您正在编写相关测试
- 通过故意引入错误并确保它被测试捕获来跳入陷阱".
真正的单元测试需要真正的隔离.单元测试不会命中数据库或打开套接字.停止嘲笑这些交互.验证您与协作者的对话是否正确，而不是此方法调用的正确结果是42".
True unit tests need true isolation. Unit tests don't hit a database or open sockets. Stop at mocking these interactions. Verify you talk to your collaborators correctly, not that the proper result from this method call was "42".
一个特定的团队是否会测试驱动所有代码，或者是否会为每一行代码编写测试优先"，这是有待商榷的.但是他们应该至少先写一些测试吗?绝对地.在某些情况下，测试优先无疑是解决问题的最佳方式.
It's up for debate whether or not a given team will take to test-driving all code, or writing "tests first" for every line of code. But should they write at least some tests first? Absolutely. There are scenarios in which test-first is undoubtedly the best way to approach a problem.
- 试试这个练习:TDD as if你是认真的 (另一个描述)
- 另请参阅:测试驱动开发和科学方法
- 测试驱动由 Lasse Koskela
- 在测试的指导下发展 OO 软件 作者:Steve Freeman 和 Nat Pryce
- 有效地使用旧代码 作者:Michael Feathers
- 示例规范，Gojko Adzic
- 要查看的博客:Jay Fields、安迪·格洛弗，Nat Pryce
- 正如其他答案中已经提到的:
- XUnit 模式
- 测试气味
- Google 测试博客
- 面向可测试性的面向对象设计"，作者 Miskov Hevery
- Test Driven by Lasse Koskela
- Growing OO Software, Guided by Tests by Steve Freeman and Nat Pryce
- Working Effectively with Legacy Code by Michael Feathers
- Specification By Example by Gojko Adzic
- Blogs to check out: Jay Fields, Andy Glover, Nat Pryce
- As mentioned in other answers already:
- XUnit Patterns
- Test Smells
- Google Testing Blog
- "OO Design for Testability" by Miskov Hevery
这篇关于单元测试采用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
