我们尝试在最近的一个项目中引入单元测试前端逻辑，但是这些测试的价值正在受到质疑。
由于我们没有对测试进行代码审查，因此它们的质量很差，开发人员复制了糟糕的测试用例，导致我们有很多无用的测试。
我仍然相信测试Presenter（我们使用MVP架构），但是让其他人认同这一点比我最初想象的要困难得多。
如何让其他人认识到前端测试的价值？是否有任何好的资源可以引用来支持我的观点？
谢谢...
前端逻辑单元测试
14
- Burt
2
2你能否提供更多关于为什么你的测试不好的信息？你所谓的“不好”的测试实际上在测试什么行为？ - Praveen Angyan
有些测试实际上并没有测试任何东西。它们应该测试以下内容以及任何异常情况。[初始化] - 我们是否正确地调用了服务的数量[提交前] - 我们是否在提交之前验证了对象并正确处理错误[提交] - 我们是否向正确的服务提交了正确的参数[提交后] - 我们是否正确地刷新了模型 - Burt
4个回答
10
- AutomatedTester
1
1使用Selenium进行的测试并不是单元测试。 - Alexander Derck
4
在测试UI时，另一个陷阱是很容易编写测试来测试框架而不是您的应用程序。或者反过来说：编写实际测试您的UI而不是UI框架可能会具有挑战性。
例如，一些团队最终编写了许多无用的测试，例如：
Given a button, when the button is clicked, the event handler should fire.
- JeffH
4
感谢您的评论。我们的前端测试确保事件被挂钩并进行适当的服务调用。最初，为了测试实际的前端逻辑，即验证或服务调用，必须对框架进行大量模拟。但是，一旦将其放入抽象基类中，我们就可以仅测试适当的逻辑。只是出于兴趣，您为什么认为测试事件是否被挂钩是无用的？ - Burt
4我的意思是你不想测试你没有编写的基础设施。如果你编写了基础设施，那么请为其编写测试，并且不要在应用程序测试中测试基础设施。我使用一个第三方框架，确保他们的按钮触发事件，所以我不对它们进行测试。如果你确实编写了UI框架，请编写测试来测试按钮是否确实触发了它们的事件。但是当你使用按钮实现应用程序时，不要测试给定按钮事件是否触发，因为框架测试已经确保了按钮会触发事件。这样清楚明了吗？ - JeffH
是的，很清楚。我们的框架采用模板模式等模式嵌入应用程序中，因此许多方法将在框架中调用，这些方法将与我们的应用程序方法联系起来，例如，在加载框架时调用XYZMethod，然后调用我们应用程序中的X、Y、Z抽象方法。因此，我们的测试类似于OnLoadXCallsCorrectServiceTest()。这样解释清楚了吗？ - Burt
@JeffH：这是非常有价值的建议，谢谢！ - T. Junghans
4
修复破窗户。这里有一篇理论链接：http://en.wikipedia.org/wiki/Fixing_Broken_Windows
防止代码质量差的成功策略是始终保持代码库的清洁和优秀状态。这意味着清理所有不良代码。虽然可能会很痛苦、耗时，但你仍需要去做。
在我们移除了项目中所有编译警告后，我们发现我们的代码质量得到了提高。人们开始关注他们要提交的代码，因为我们传达出一个信号：提交不好的代码（甚至是警告）是不行的，没有人想成为第一个破窗户的罪魁祸首。
- ez.
1
对我来说，问题在于维护测试的成本和捕获否则无法捕获的错误的概率之间的权衡。假设您仍将对实际UI进行一些视觉测试（否则您将很难测试美学）。
例如，您可以仅关注Presenter的某些方面。例如，非平凡格式化程序，使用许多有趣的值进行练习。
我怀疑说服的一种方法是缓慢前进。首先尝试找到低成本的测试。
- djna
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接