单元测试前端逻辑

时间:2009-08-11 10:57:37

标签: unit-testing testing tdd agile mvp

我们已经尝试在最近的项目中引入单元测试前端逻辑,并且测试的价值受到质疑。

我们没有对代码进行代码审查,因此它们的质量很差,开发人员复制了不良测试,导致测试结果较差,因此我们进行了大量的废话测试。

我仍然认为测试演示者(我们使用MVP)是有价值的,但让人们参与其中比我原先想象的要困难。

我怎样才能让人们认为前端测试很有价值,有没有人有任何好的资源可以指点我,支持我这个?

...谢谢

4 个答案:

答案 0 :(得分:10)

单元测试前端逻辑非常困难,因为有很多部分可以像前端的服务器端代码更改一样,客户端更改都会影响应用程序的显示方式。

在Google测试blog上,他们讨论了测试MVP所有部分的价值以及通过存储昂贵的部分here来测试AJAX的价值。 Misko Hevery讨论了不同的测试here,我觉得前端测试属于他的大型测试类别,因此总是有假阴性/阳性的可能性,但他们需要进行分类,因为它们仍然提供了很多价值

前端测试非常有价值,因为它们会检查用户功能是否已下降。这就是SeleniumWatir等工具如此受欢迎的原因。


答案 1 :(得分:4)

修复损坏的窗口。 这是理论http://en.wikipedia.org/wiki/Fixing_Broken_Windows

的链接

防止代码质量不佳的成功策略是始终保持代码库的清洁和声望。这意味着清理所有不良代码。这可能是痛苦的,也很耗时,但无论如何你都需要这样做。

在我们删除了项目中的所有编译警告后,我们发现我们的代码质量一直在提高。人们开始关心他们检查的内容,因为我们发出一个信号,表示不能检查错误的代码(即使警告不正常),也没有人想成为第一个打破窗口的人。

答案 2 :(得分:4)

测试用户界面时的另一个缺陷是,最终编写测试框架而非应用程序的测试非常容易。或反过来说:编写实际测试UI而不是UI 框架的测试可能具有挑战性。

例如,一些团队最终编写了大量无用的测试,例如:

Given a button, when the button is clicked, the event handler should fire.

答案 3 :(得分:1)

对我来说,问题是在维护测试的成本和捕获其他不会被捕获的错误的可能性之间进行权衡。据推测,你仍然会对实际用户界面进行一些视觉测试(否则你会很好地测试美学)。

您是否可以仅关注Presenter的某些方面。例如,一个非平凡的格式化程序,它具有许多有趣的值。

我怀疑说服的一种方法是慢慢进行。最初尝试找到省力的测试。