Bur*_*urt 69 tdd agile automated-tests unit-testing
我们已经尝试将单元测试引入到我们当前的项目中,但它似乎没有起作用.额外的代码似乎已经成为一个维护问题,因为当我们的内部框架发生变化时,我们必须绕过并修复任何挂起它的单元测试.
我们有一个抽象基类,用于单元测试我们的控制器,它作为模板调用子类的抽象方法实现,即Framework调用Initialize,所以我们的控制器类都有自己的Initialize方法.
我曾经是单元测试的倡导者,但它似乎并不适用于我们当前的项目.
任何人都可以帮助确定问题以及我们如何使单元测试对我们而不是对我们有效？
cwa*_*ash 108
如果它们是针对程序风格的代码编写的,那么测试就可以成为一种保证,这些代码严重依赖于全局状态或者位于丑陋方法的深层.如果您使用OO语言编写代码,请有效地使用OO构造来减少这种情况.
代码中的阻塞点比其他部分更频繁地改变.在您的代码库中执行此操作,您的测试将变得更加健康.
尽你所能缩小测试及其执行的周围环境.
您可能无法删除所有重复项,但仍会尝试将其删除,因为它会导致疼痛.确保你没有删除那么多的重复,以致有人无法进入,并一目了然地告诉测试的内容.(有关同一概念的替代解释,请参阅Paul Wheaton的"邪恶单元测试"一文.)
想想记录和回放Selenium测试所涉及的复杂性,以及在测试单个方法时可能会发生什么变化.
真正的单元测试需要真正的隔离 单元测试不会打到数据库或打开套接字.停止嘲笑这些互动.验证您是否正确地与协作者交谈,而不是此方法调用的正确结果是"42".
讨论一个特定团队是否会采用测试驱动所有代码,或者为每行代码编写"测试优先",这都存在争议.但他们应该先写一些至少一些测试吗？绝对.在某些情况下,测试优先无疑是解决问题的最佳方式.
cjk*_*cjk 19
您是否在测试足够小的代码单元？除非您从根本上改变核心代码中的所有内容,否则您不应该看到太多更改.
一旦情况稳定,您将更加欣赏单元测试,但即使是现在您的测试也突出了您的框架变更的传播程度.
这是值得的,尽可能坚持下去.
Mar*_*son 12
如果没有更多信息,很难对你为什么遇到这些问题做出体面的准备.有时,改变界面等不可避免地会破坏很多东西,有时甚至是设计问题.
尝试对您所看到的失败进行分类是个好主意.你有什么问题？例如,由于API更改,它是测试维护(如在重构后编译它们!),还是由于API的行为变化？如果您可以看到模式,那么您可以尝试更改生产代码的设计,或者更好地隔离测试以防止更改.
如果在很多地方改变一些东西会对你的测试套件造成无法估量的破坏,你可以做一些事情(大多数只是常见的单元测试技巧):
开发小的代码单元并测试小的代码单元.在有意义的地方提取接口或基类,以便代码单元中包含"接缝".你必须接受更多的依赖关系(或者更糟糕的是,使用'new'在类中实例化),你的代码将更容易被改变.如果每个代码单元都有一些依赖项(有时是一对或根本没有),那么它最好不要改变.
只能断言测试需要什么.不要在中间,偶然或无关状态下断言.通过合同设计和按合同测试(例如,如果您正在测试堆栈弹出方法,请不要在推送后测试计数属性 - 这应该在单独的测试中).
我看到这个问题很多,特别是如果每个测试都是一个变种.如果任何偶然状态发生变化,它会破坏在其上声明的所有内容(无论是否需要断言).
与普通代码一样,在单元测试中使用工厂和构建器.我学会了一个大约40个测试需要在API更改后更新的构造函数调用...
同样重要的是,首先使用前门.如果可用,您的测试应始终使用正常状态.只有在必要时才使用基于交互的测试(即没有要验证的状态).
无论如何,我的要点是,我试图找出测试破坏的原因/地点并从那里开始.尽力使自己与变化保持隔离.