TotT

有多少测试才算足够?

每一个软件开发人员和团队都会遇到一个熟悉的问题:“有多少测试足以证明一个软件版本是合格的?”这在很大程度上取决于软件的类型、用途和目标受众。

继续阅读

不要模拟( Mock )不属于你负责的组件!

本文将讨论如何以及在什么地方应该使用 Mock 技术来模拟第三方库或外部组件。 虽然对外部组件的模拟( Mocks )让你能够验证系统的边界,而不必真正使用外部系统

继续阅读

不要过度依赖于 Mocks!

在为代码编写测试时,通过对代码的依赖关系进行 Mock ,让测试写起来似乎更容易。 然而,过度使用 Mocks 可能带来几个问题: 让测试代码更难以理解。与直接使用代

继续阅读

库文件最好少使用硬编码值!

你可能会遇到这样一种情况:你的某个函数总是使用相同的一个值,那么你此时可能会定义一个常量。这是一种好的做法,因为它避免了“魔数”,并改善了代

继续阅读

测试 UI 逻辑,请使用“正门优先原则”!

针对 UI 逻辑的自动化单元测试,当然是使用“正门优先原则” ,即:尽可能使用 Public 的真实实现代码。 一个对象( Object )会有几种接口。例如,它会有一个为大多数

继续阅读

使用自描述性的测试方法名

在测试用例名字中可以包含测试场景和期望的结果,这有以下几个好处: 你一眼就可以看出测试意图。 如果你想了解某个类所有可能的行为,你所需要做的只是

继续阅读

如何写好端到端的自动化测试

端到端测试就是用来测试整个系统的,即:从给这个系统输入信息开始,到获取返回的输出信息,将被测系统看作一个黑盒。 端到端测试可以捕获整个系统中出

继续阅读

仅验证与其被测行为相关的方法参数!

每个测试只应该验证一个行为,这可以使测试用例更可读,更能适应变化。 下面这段测试代码为 MockUserPrompter 的所有参数指定了精确值。一旦被测试的代码发生更改,这些

继续阅读

仅验证与其被测行为相关的方法参数!

每个测试只应该验证一个行为,这可以使测试用例更可读,更能适应变化。 下面这段测试代码为 MockUserPrompter 的所有参数指定了精确值。一旦被测试的代码发生更改,这些

继续阅读

测试用例太 DRY 了? 应该让它们 DAMP!

下面的测试用例遵循了 DRY 原则 (“Don’t Repeat Yourself”), 它是鼓励重用,消除重复的一个最佳实践,例如, 通过抽取 helper 函数 或 通过使用循环的方

继续阅读