单元测试 – 什么是良好的单元测试?

前端之家收集整理的这篇文章主要介绍了单元测试 – 什么是良好的单元测试?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我相信大多数人都在写大量的自动化测试,你也遇到了一些常见的陷阱,当单元测试。

我的问题是,你是否遵循任何行为规则进行测试,以避免未来的问题?更具体的:好的单元测试的属性是什么,或者你如何编写测试?

鼓励语言不可知的建议。

让我开始通过插入源 – Pragmatic Unit Testing in Java with JUnit(有一个版本与C#-Nunit太..但我有这一个..它的大部分不可知。推荐)

好的测试应该是一个TRIP(这个缩写是不够粘 – 我有一本书中的骗子打印输出,我不得不拉出,以确保我有这个权利..)

>自动调用测试以及检查PASS / FAIL的结果应该是自动
>全面:覆盖;虽然错误往往集中在代码中的某些区域,请确保您测试所有关键路径和方案..使用工具,如果你必须知道未测试的区域
>可重复:测试应每次产生相同的结果。测试不应该依赖于不可控的参数。
>独立:非常重要。

>测试应该一次只测试一件事。多个断言是可以的,只要他们都测试一个特性/行为。当测试失败时,它应该确定问题的位置。
>测试不应该依靠彼此 – 隔离。没有关于测试执行顺序的假设。在每次测试之前,通过适当地使用安装/拆卸来确保“干净的石板”

> Professional:从长远来看,您将拥有与生产一样多的测试代码(如果不是更多),因此遵循与测试代码相同的良好设计标准。井考虑方法 – 具有意向显示名称的类,无重复,具有良好名称的测试等。
>良好的测试也运行速度快。任何需要超过半秒的运行的测试..需要处理。测试套件运行时间越长,它运行的频率就越低。更多的变化,开发者将试图偷偷在运行之间..如果有什么打破..它需要更长时间才能找出哪个更改是罪魁祸首。

更新2010-08:

>可读:这可以被认为是专业的一部分 – 但是它不能被强调。酸性测试将是找到一个不是你的团队成员的人,让他/她在几分钟内找出测试中的行为。测试需要像生产代码一样维护,所以即使需要更多的努力,也要易于阅读。测试应该是对称的(遵循模式)和简洁(每次测试一个行为)。使用一致的命名约定(例如TestDox样式)。避免杂乱的测试与“附带的细节”..成为一个极简主义者。

除此之外,其他大多数都是减少低收益工作的指南。 “不要测试您不拥有的代码(例如第三方DLL)。不要去测试getters和setters。注意成本效益比或缺陷概率。

原文链接:https://www.f2er.com/javaschema/283049.html

猜你在找的设计模式相关文章