我目前从 BDD 开始——我之前没有写过任何测试。我总是尽量让我的模型胖而我的控制器瘦。
你怎么看 - 控制器规格是必要的吗?
此致
是的。测试是否进行了正确的调用,并在必要时进行了正确的重定向,并测试了是否呈现了正确的页面。因此,测试您的应用程序是否按预期运行。
就我自己而言,我试图了解在测试中寻求高水平的代码覆盖率与维护一组可能非常脆弱的测试的长期成本之间的平衡。
假设我们有一个控制器
try {
result = mode.doSomething();
if (result.count == 0 )
message = "none found"
redisplay criterion page
else if (result.count == 1 )
display detail page
else
display list page
} catch exception {
message = "bad things happened, please try again"
redisplay criterion page
}
一个初步的想法是,三个计数案例(0、1、许多)的测试可能比例外案例的测试价值更低,并且更容易改变。价值较低,因为 a)。其他测试将在页面显示中发现问题 b)。测试非常接近于简单地重现代码。
code: go to page X
test: did you go to page X?
如果开发人员选择了错误的 X,那么他的测试也会出错!如果 UI 的可用性测试表明 Y 是更好的显示页面,那么我们会同时更新代码和测试。测试真的有什么收获吗?
而异常情况在正常的 UI 测试中可能很难进行,而使用 mock 进行测试非常容易。而且,异常之后的行为是我们确实需要正确处理的事情。
你怎么看 - 控制器规格是必要的吗?
如果您将它们与良好的集成测试结合起来,我认为它们是不必要的。我发现应用程序的可用性非常重要,因此对于控制器/视图的每次更改,我都会单击应用程序并了解它的感觉。在我看来,为控制器和视图创建“哑”测试并没有太多额外的价值。
对于集成测试,我使用的是 Cucumber。这使得测试整个堆栈并确保您的应用程序以您想要的方式执行成为可能。对于业务逻辑(胖模型),我仍然使用 RSpec。