代码质量

有多少测试才算足够?

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

继续阅读

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

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

继续阅读

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

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

继续阅读

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

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

继续阅读

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

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

继续阅读

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

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

继续阅读

单元测试一定要聚焦

写测试时,应该是每个场景都应该在独自的测试用例中进行验证,它的好处在于: 逻辑更容易理解,因为在每个测试方法中需要理解的代码更少。 每个测试中的

继续阅读

要测试行为(Behaviors),不要测试方法(Methods)

在编写一个method()之后,只需编写一个测试,就可以轻松地验证方法的所有功能。但是认为测试与public method方法应该是一对一的关

继续阅读

自动化测试中,不得不知的替身对象

自动化测试中,我们常会使用一些经过简化的,行为与表现类似于生产环境下的对象的替身。引入这样的替身对象能够降低构建测试用例的复杂度,允许我们独

继续阅读

要测试 Public APIs,而不是实现细节

公有的 API 可能被任何调用者所使用,而调用者可能会将从任意组合的参数引入到该方法中。 我们当然希望,所有的可能性都能被测试用例覆盖。 这样的话,我们

继续阅读