在某些情况下,单元测试和TDD等比它们的价值更麻烦?
我想出的一些事情是:
还有什么其他案例?
答案 0 :(得分:3)
我相信你的前两点无效。
当然,应用程序的方面无法经过单元测试 - 可视化布局(屏幕或打印)就是这样一个方面,一般的可用性 - 无法真正正式指定的东西。
单元测试可能不适用的情况是,当您面对的是现有的应用程序时,无法考虑可测试性或模块化(Big Ball of Mud反模式)。但即便如此,如果你知道你必须在相当长的一段时间内维护和扩展这种野兽,那么找到一种方法来自动测试应用程序的至少某些部分几乎总是可行和有用的。没有人说你必须编写一个测试套件,在做任何其他事情之前可以实现100%的代码覆盖率。
答案 1 :(得分:1)
我不确定它是否无益。在某些情况下,它可能会更加困难,您可能会选择不使用它 - 例如,在UI的可视布局中。有时可能会浪费精力 - 例如,单元测试设计器生成的代码或框架,而不是由您编写的。生成数据不应成为单元测试的障碍。您的测试应该足够小并且足够集中,以至于您通常不需要为任何单个测试生成整个数据集,因此在这些情况下,模拟是非常有用的技术。如果我发现自己一遍又一遍地嘲笑同样的事情,我有时会把它合并成一个假的数据库类,所有的测试都可以依赖它。
单元测试和运行代码都不会验证其正确性。单元测试可以帮助消除错误,特别是使用TDD,并确保找到的错误是固定的。如果您需要确保代码正确,则需要应用不同的基于逻辑的技术来证明正确性。这些超出了单元测试的范围。
答案 2 :(得分:0)
我不会说有任何自动化测试无益的情况。
肯定会有一些不太有帮助的地方。我认为创建夹具数据不是其中之一。有一些工具可以帮助,比如factory_girl(至少在Ruby中)。事实上,如果你的模型非常复杂,你需要创建十几个具有各种关联的对象,我会考虑代码的味道,也许模型不是那么简洁。
尽管如此,有几个案例的缺点可能超过了好处。前几天我写了一些代码,要求外部进程。我不关心输出,我不关心返回代码,我甚至不关心它是否工作正常,它完全是火和忘记,如果某些东西不能正常工作,另一个过程将会清理干净,后面。
在这种情况下,我没有费心去编写任何测试,因为设置虚假的外部程序来验证我的论据等等,这样做的好处并不值得。
答案 3 :(得分:0)
对此有一些随意的想法:
但这些仍然是个案。我也认为它们几乎总是可行的,从长远来看通常会比你在开始时投入更多的回报。
答案 4 :(得分:0)
* When generating test data is tricky: Sometimes, being able to come up with valid, non trivial test data is a challenge in itself.
当您需要系统与“完整数据集”处于“上下文”时,您所做的不是单元测试。它正在测试,但你对“单位”的压力很大。您需要进行较小的测试。 TDD的难点在于使您的代码处于这样的形状,您可以在小型中对其进行测试。这很有价值,但并不容易。如果你进行test-after(非TDD),那么几乎不可能避免你的情况。
因此,当你想测试大于单位的东西(即类中的方法)时,你会想要使用像UAT之类的东西。但在这种情况下,您仍然需要像练习TDD一样对各个函数进行测试。
* When the only practical way of verifying correctness of the code is to run it.
但代码 在单元测试中运行。你的意思是什么时候在或其他什么地方运行?
* When you're testing visual elements of the design.
我认为这是你的第二个要点,但我猜不是。尝试在UT中测试布局很难并且通常都没有用。这样的测试很脆弱。
因此,在某些情况下使用UT进行大型子系统测试或验证屏幕布局可能没有用。但即便如此,对于仍然有90%的工作来说,这是非常有价值的。
答案 5 :(得分:0)
我认为迈克尔总结得非常好:“不能真正正式指明的事情”。事实证明,有很多事情无法正式指定。可用性就是一个例子(虽然一旦你决定哪种行为可用,你当然可以并且应该测试那种行为!)。有点矛盾的是,许多数字训练任务无法正式指定:例如天气预报。目标当然是预测明天的天气,但这不是正式的规范。所以你可以测试你使用的算法是否做了他们应该做的事情(计算平均值,反转矩阵,可以正式指定的东西),但是你的天气预报程序可以通过所有的测试,但仍然有90%的时间是错的。或者你可以使用大量的历史数据来测试算法是否能产生良好的预测,但这很危险,因为它很容易导致算法只对你使用的历史数据准确,而不是一般。这可能意味着您的单元测试需要数小时或数天才能运行。更糟糕的是,您的算法可能具有必须“调整”的参数,例如对于所使用的测量仪器,每个算法的最佳参数可能不同,因此单元测试需要手动交互才能找到好的参数。在理论上可能,但可能不是很有用。我想相同的论点将适用于OCR,ICR,许多信号处理任务,人脸识别(以及许多其他图像处理任务),典型的Photoshop工具,如“红眼消除”或搜索引擎排名算法(仅举几个例子) )。
答案 6 :(得分:-2)
我坚信有思想的测试;但是,我发现单元测试和TDD主要是浪费时间。
如果您的开发人员不是高素质的话,单元测试可能会有一些好处。