你对无所不在的“测试,测试,测试”有什么看法?“原则?

一个词的答案是“复杂性”。真正的答案是“不必要的复杂性”! 会计原则在过去30年里没有改变。那么,为什么今天要写一个会计系统那么困难呢?有一个图形用户界面是很好的,但我们是否必须走极端?

多年来,软件开发一直处于恶性循环之中。复杂性是自我补充,而不是减少它,我们只是把它隐藏在包装机的层和层下面。最终会有一些东西付出。

当我们喜欢形式而不是功能时,我们必须付出代价。

事实上,我经历过相反的情况。虽然它以前是一个运行直到工作的案例,但我现在进行单元测试直到测试通过…这看起来至少是 合理地 据我所见,共同转变。

我不得不说第一次只使用打字错误的代码 从未 在我的经验中是很正常的。不同的是,现在我可以更快地发现问题,如果旧问题又出现了,我也会发现。我有时可以管理相当短和简单的代码位而不出错(在堆栈溢出上发布可以提高这种能力),但是大型复杂的系统呢?见鬼不。

回答你文章的题目“测试,测试,测试”原则是一个很好的原则,在我看来…但我不认为这与重复运行整个程序有关。我经常把它与运行单元测试联系起来。我很少需要在单元测试中使用调试器——通常失败会通过检查使原因变得相当明显,因为只测试了少量代码。

在以后的几年中,开发人员是否会意识到“100%确定性”实际上可能不正确?开发软件是非常复杂的,即使这些工具经过多年的发展,我们也意识到编写好的代码是困难的。的确,调试和自动化的单元测试使我们更有效率,但是我们仍然会产生错误,就像以前那样,直到现在我们有了不同的工具来捕获它们。

您可以编写您认为自己100%知道它做什么和不做什么的代码,但总是有您没有想到的边缘情况或抛出您不期望的异常。有时,在调试程序的帮助下,尝试和错误编程可以成为缩小问题范围的有用工具。

重要的是要知道哪些工具可以帮助您用最少的错误生成代码。

我发现测试方法可以帮助我设计代码。有时,必须完成的工作过于复杂,无法一劳永逸地完成。测试迫使我把它分成更小的部分,当我解决这些问题时,我可以把它们组合成一个更大的整体。

我认为优势是间接的:当您接受测试和单元测试时,您必须以一种您可以实际编写测试的方式编写应用程序:

• 类需要以这样的方式编写:您可以实例化单个对象,而不需要整个应用程序及其周围的操作系统,只需要几个辅助对象。这意味着您需要最小化依赖关系,并使与周围系统的所有通信都显式化。

• 实现测试用例意味着您必须找到一个最小的命令和调用序列,使您的类做一些有意义的事情。这常常指向笨拙的设计决策,或者向您显示类对于某些目的来说非常难以使用。

总而言之,当您接受测试时,您最终会得到一个在组件之间相互依赖性最小的系统,并且测试用例作为如何使用组件的文档。

测试(执行您的系统)告诉您一些关于“存在bug但不存在bug”的事情(afaik这个术语是由dijkstra创造的)。它指出了测试套件的强度是测试的关键的方向:“您有如此多的测试用例,您可以说,许多错误并不存在。这意味着软件的大部分工作都如预期的那样”。

具有强大/强大测试套件的一些示例:

• 很多代码是由单元测试执行的(传统的覆盖范围术语)
• 您没有假阴性测试(显示绿色的测试,但实际上应该是红色的测试)。假阴性测试是邪恶的,因为它们给你错误的测试用例质量的感觉。有关良好测试断言和错误否定的详细信息,请参见 blog-entry#1 和 blog-entry#2 .
• 需求已经被很好地理解了(我见过很多情况,自动化测试测试测试错误,开发人员误解了业务需求)。因为开发人员是绿色的,但是对于业务来说,系统并没有按预期工作(另一种错误的、负面的例子,但是在更高的层次上)。

在某种意义上,程序的正确性只有在用数学证明完成时才能得到证明(这只会对生命关键和资金密集的系统产生回报)。尽管如此,您仍然可以通过自动化测试实现很多功能(除了单元测试之外,自动化集成测试总是有很大帮助)。

关于调试:我像以前一样经常使用调试,但有时当向代码添加新功能(我的新测试用例显示为绿色)时,我会破坏其他测试用例。通过断言,我立即发现出了问题,但仍然没有找到bug。对于定位bug,调试仍然很有用(对于红色测试用例,我执行有问题的代码路径,对于调试器,我定位bug)。

如果您对测试自动化感兴趣,请看一看杰作 xUnit Test patterns .

我读过一本书(KentBeck的《TDD实例》),这本书确实将“试错法”推向了极端:但更像是“让单元测试工作”。尽管如此,我还是无法完成这本书——这是一个罕见的事件,特别是我真的希望能得到更好的理解。尽管如此,提交明显低能的代码以备日后改进让我不寒而栗。

科学: 自动化测试有其优点。然而,他们不是据称的银弹。单一的检测方法不足以发现缺陷,其它方法检测率较高。

肠道感觉: 我们的问题是日益复杂的方面。复杂性与我们必须管理的代码量高度相关。因此,TDD试图解决 多码 通过写作 更多的代码 .

优势: 我们现在有了一个既定的形式主义,使测试可重复、负责并立即记录下来。这绝对是一个摆脱“在我的机器上工作”和“奇怪,它昨天工作了,我会给你最新的动态链接库”陷阱的方法。

我目前正在练习测试驱动开发(TDD),或者至少编写许多单元测试来验证我的大多数/所有代码的行为是否符合我期望的方式。采用这种方法迫使我从消费者的角度来看我的程序。此外,在编写测试时,我经常想到边界限制、我最初没有想到的其他场景等等。

我现在已经到了我害怕改变旧程序的地步,因为我害怕我会破坏一些东西。与运行一组单元测试相比,回归测试是繁重的。