我需要测试一切吗？

28

我将在Ruby on Rails中开始我的第一个实际项目，并且强迫自己编写TDD测试。我看不出编写测试的真正优势，但是由于它看起来非常重要，因此我将尝试。

是否有必要测试应用程序的每个部分，包括静态页面？

testing tdd

— Matteo Pagliazzi
source

9

这真的不是关于Rails的问题。这更多是TDD问题。

— 乔恩·斯特雷耶

4

@JonStrayer：是吗？您确定RoR的答案与.NET相同吗？我建议RoR故意降低了测试成本，而没有编译器形式的类型安全性会大大增加测试的好处。

— pdr 2012年

1

由于某些原因，这个问题使我想发布Nero上尉大喊“测试一切！！”的图像宏。

— 梅森惠勒2012年

3

没有看到编写测试以及出于盲目的信念而编写测试的真正优势，这听起来并不正确。继续进行而无需编写测试，过一会儿您将遇到意外的回归并知道为什么要进行测试。

— ZJR 2012年

1

等待，直到您决定重新构建代码。每次引入大量更改时，您都需要验证功能。没有测试，您将需要遍历您的应用程序并手动测试所有功能。引入另一个较大的更新，您将不得不再次进行。单元测试只是确保一切按预期工作的“便宜”方法。

— Evan Plaice 2012年

47

TDD与测试无关，而与设计有关。编写测试会迫使您考虑该类应该如何工作以及需要哪种接口。这些测试是一个令人愉快的副作用，可以使以后的重构更加容易。

因此，牢记这一点，静态页面的行为是什么，界面是什么？

我的第一个答复是“无”和“无”。

— 乔恩·斯特雷尔
source

所以没有测试静态页面？

— Matteo Pagliazzi 2012年

TDD在某种程度上与设计有关。但是您仍然需要一个体系结构。如果没有构架，就很难想象通过一系列测试如何自然发展。

— 罗伯特·哈维

@MatteoPagliazzi取决于测试的级别（单元测试/集成测试等），可能需要一两个来确认是否可以访问静态页面。但这对于单元测试来说太高了。

— 伊兹卡塔2012年

1

@RobertHarvey我没说不做任何测试。我说过不要对静态页面进行单元测试。

— 乔恩·斯特雷耶

@JonStrayer：TDD的人倾向于将TDD当作设计中不可思议的灵丹妙药。如果您不是这个意思，我深表歉意。:)

— 罗伯特·哈维

32

这始终是成本效益分析。破坏功能的代价是什么？如果成本很高，则应进行彻底的测试。如果成本很低，请轻松进行测试或根本不进行测试。

还需要考虑上市时间。也许对您来说，提供主要工作的功能要比迟迟提供完全工作的功能更好。

在一般的IMO中几乎不可能回答这些问题。

我认为，在某些功能比您最初意识到的更重要的情况下，保持测试能力更为重要。

— 道格T.
source

另外，我认为静态页面中的错误比逻辑错误，设计错误和TDD通常用来防止的错误类型更容易修复。发现和修复静态页面的错误都可能相当容易，而且我的印象是TDD用于在花费比预期更长的时间时缩短这两个过程。：D

— Gordon Gustafson，2012年

我不会这么认为。如果您曾经处理过晦涩的浏览器版本行为或奇怪的javascript内存问题，那么您可能已经锻炼了很多。有时，后端语言可能更可靠，更标准。有时。也许您是在谈论html之类的static，但没有javascript。

— 迈克尔·杜兰特

8

我会说“是”。如果您的测试涵盖了最简单的功能和代码，那么您可以放心，添加新代码不会导致就地代码退出工作。同样，对遇到的每个错误进行测试，可以防止回归。

— 布鲁斯·埃迪格（Bruce Ediger）
source

“那么，您可以放心，添加新代码不会导致就地代码退出工作”，那样，我就不应该碰触我之前编写的任何代码，而不必添加新方法？

— Matteo Pagliazzi 2012年

好吧，不。但是，如果您添加更改这些依赖关系的新代码，则当前“有效”的代码之间无法预料和计划外的依赖关系可能会导致问题。另外，如果您认为测试很不正确（我认为这很常见），则必须修改测试本身，然后也许还要修改该测试产生的代码。

— Bruce Ediger 2012年

@Andy绝对是胡说八道。测试属性设置器和获取器既简单又重要。如果他们不起作用，通常整个班级都会崩溃。例如，在多线程应用程序中，如果集合不能阻止并发获取，那么您将遇到数据损坏的问题，这可能需要花费数小时才能解决问题，因为数据源是正确的，但是获取结果不会，或者如果您的设备也无法更新更新时间，则您的数据可能变得无法同步。如果getter和setter方法是真的微不足道，你可以只作属性public

— deworde

@deworde恐怕使实例成员线程安全并不常见。通常，控制对非ttt安全类型的访问比试图使它们成为线程安全的更为常见。无论如何，要测试的是成本效益的东西，另一个答案指出。您可以花时间编写针对吸气剂或吸气剂的测试，也可以测试系统应该封装的实际行为。

— 安迪

3

是的，您应该测试所有内容...

您将不必为所有内容编写自动测试。对于您的静态页面，请使用Selenium http://seleniumhq.org/来确保一切正确。

根据我的经验，有些前端事情几乎不可能编写测试用例，但这就是为什么您实际上想要使用Mark 1眼球进行测试的原因。

— 施莱斯
source

我不同意。如果您无法通过模拟或传递数据来实现它，那么为什么要在代码中使用它。getter和setter不需要自己的测试，可以通过系统的其他单元测试来测试它们，以验证期望的功能。

— Schleis 2012年

当然，setters / getters是与其他测试间接测试的，但是当有人说“测试所有内容”时，我认为它们的意思是专门为此类事情创建测试。我总是告诉人们“测试重要的事情”。对我来说，像setter和getter之类的东西不适合该定义。

— 安迪

2

测试与编码一样重要。您必须听到一句俗语：“如果出现问题，那就可以了”。INMO，在用于提高质量的许多软件工程技术中，测试是帮助您及早发现问题的最有价值的技术。

尽管不可能进行所有测试（特别是对于小型团队和大型系统），但这并不意味着您完全跳过了测试。测试值得吗？请参阅Wiki-SoftwareTesting中的 “及早发现故障”部分。

— 没有机会
source

2

如果以这种方式编写，则TDD测试也可以成为生活规范。测试方法的名称应对业务用户有意义。

— Chriseyre2000
source

2

正如其他人提到的那样，在Ruby on Rails测试中，它比（大多数）其他语言中的重要得多。这是由于缺少编译器。

诸如Delphi，C ++，VB.NET等语言是已编译的语言，并且您的编译器会在方法调用中出现很多错字，例如拼写错误。在Ruby on Rails中，只有运行特定代码行或使用显示视觉警告的IDE，您才知道代码中是否有错字或错误。

由于每行代码都很重要（否则就不会出现），因此您应该测试编写的每个方法。这比您遵循一些基本的TBDD工具听起来要简单得多。

我发现瑞安·贝茨（Ryan Bates）的《如何测试》的Rails对我来说是无价的，并且确实强调了TBDD的简单性（如果正确完成的话）。

— 詹姆斯
source

1

如果您确实在使用TDD方法，那么您在没有通过单元测试的情况下就不会编写代码。

— 韦西亚德
source

2

是的...但是例如在静态页面中我应该测试什么？存在吗？内容和链接是否存在？也许我错了，但这似乎是在浪费时间...

— Matteo Pagliazzi 2012年

1

我倾向于认为TDD方法论适用于您的逻辑。您的静态页面是html文件吗？永不改变的MVC视图？如果是后一种情况，我想您可以测试您的控制器是否返回正确的视图。我认为更重要的是要记住，TDD应该帮助您开发符合您的规范的标准，而不仅仅是“测试” ...

— wessiyad 2012年

我假设您只是为包含框架组件的静态页面提供服务。如果您的方法都无法触及该页面，则实际上没有任何测试。您也不需要测试Rails。我认为有人已经涵盖了。

— 艾里克·雷彭

0

我会说不要从TDD开始。一般而言，如果您花了更多时间学习架构策略，请做出明智的决定。尽管您可能会开始相信，TDD不会让您跳过该作业。

这是我的问题。当您说似乎永远浪费TDD的东西上浪费了很多时间时，当您在大量依赖项中没有想到的一件事被破坏时，您将不胜感激。当您指出在编写应用程序之前无法预测此类情况时，这是呃...为什么我们进行测试，他们告诉您，实际上这更多是关于设计而不是测试，即使测试很方便。

但是笨拙的设计产品不是难解的连锁依赖的巨型链条吗？

那是什么呢？

这是一个想法。首先，不要考虑“设计模式”中面向对象设计的以下两个原则：

“编程到接口，而不是实现”

也就是说，您的对象不应该在乎谁在进行呼叫或如何进行呼叫。只有输入了正确的args并且它们从其他对象中调用的方法才可以按预期工作。在大多数情况下，您的依赖关系链应该位于一个链接点，即调用方的方法调用以及将args放入您的方法的位置。那是您在发生故障时记录和验证并发送有用的消息以进行调试的地方。

和：

“类继承中的重要对象组成”

谁是假人？是在一个复杂的级联继承方案中为某类做某事的家伙，涉及到30个类，导致边缘案例破损，还是首先提出该体系结构的开发人员？TDD可能会比您没有的时候更快地帮助您解决比萨斜塔之内的问题，但这是否使下一次尝试修改该代码灾难的端点之一的痛苦减轻了？

这就是我困扰我的地方。TDD是否真的有助于设计或是否支持不良体系结构？在我看来，它有可能成为一种自我实现的策略。您的团队不必对糟糕的架构承担更多的责任，这些细粒度的测试组件似乎就越有用，但是最终您的应用程序变得越来越大，可以使用的PITA（假设他们从一开始就没有对架构进行过多考虑地点）。而且，如果不承认其后果，那就太容易了，这总是您在处理要随着时间进行升级和修改的应用程序时可能犯的最昂贵的错误。

— 埃里克·雷彭（Erik Reppen）
source

-1

要回答这个问题，请考虑“这里可能出什么问题”。特别是，如果您更改“代码”（标记/其他），您将如何确定自己没有破坏页面。好吧，对于静态页面：

它可能无法渲染
它可能会渲染不正确
JS可能无法加载
图片的路径可能不起作用
链接可能坏了

就个人而言，我建议：

编写一个selenium [1]测试，以检查页面上期望的一个字符串（如果可能，请靠近底部）。这验证了它呈现。
检查是否没有JS错误（我认为硒允许这样做）
通过html验证器以及可能的链接检查器运行静态页面。
我还没有找到喜欢验证JS的工具，但是您可能会发现使用jslint或jshint成功。

这里的好处是您需要可重复使用，易于使用并且可以在测试运行器中自动运行的功能。

— 保罗·比格（Paul Biggar）
source

-1

只是为了添加所有已经非常好的答案，这是我对要测试什么以及不测试什么的思考：

做测试：

商业逻辑
应用逻辑
功能性
行为，
所以，除了：

不要测试：

常数
介绍

因此，进行以下测试是没有意义的：

assert wibble = 3

和一些代码说

wibble = 3

而且，测试演示性内容也没有意义，例如图标是否为长春花蓝色，标题所用的字体等等。

因此，您问“我应该测试静态页面”，答案是：在网站功能，业务逻辑或行为的一部分范围内对其进行测试。

因此，在我们的应用程序中，我们进行了一项测试，以检查网站的每个部分是否都适用条款和条件-匿名用户，登录用户，仪表板，应用程序内部屏幕等都可以使用。它只是检查是否存在每页上都有一个称为“条款和条件”的链接，该链接有效，然后测试表明，当它到达页面时，它看起来就像是“条款和条件”，足以确保您自己是正确的页面，无需“测试常量”或“测试演示文稿” ...因此您可以检查文本是否正确，例如，无需检查特定的字体大小或文本布局...

— hwjp
source