你的单位测试有多深？

Question

你的单位测试有多深？我发现关于TDD的事情是它需要时间来设置你的测试并且自然是懒惰我总是希望尽可能少编写代码。我似乎做的第一件事是测试我的构造函数已经设置了所有的属性，但这是否有点过分？我的问题是你在单元测试中写出了什么级别的粒度？..是否有一个测试太多的情况？

Answer 1

我得到的代码是有效的，而不是测试，所以我的理念是尽可能少地测试以达到给定的置信水平（我怀疑这种信心水平与行业标准相比很高，但这可能只是傲慢） 。如果我通常不会犯一个错误（比如在构造函数中设置错误的变量），我不会测试它。我确实倾向于理解测试错误，所以当我有复杂条件的逻辑时我会格外小心。在对团队进行编码时，我会修改策略以仔细测试我们共同出错的代码。

不同的人会根据这个哲学有不同的测试策略，但这对我来说似乎是合理的，因为对于测试如何最适合编码的内循环的理解不成熟。从现在起十年或二十年后，我们可能会有一个更普遍的理论，即哪些测试要写，哪些测试不写，以及如何区分。与此同时，实验似乎是有序的。

Answer 2

为您希望破坏的事物和边缘情况编写单元测试。之后，应该在bug报告进入时添加测试用例 - 在编写bug修复之前。然后开发人员可以确信：

1. 错误是固定的;

2. 该错误不会再出现。

根据所附的评论 - 我想这种编写单元测试的方法可能会导致问题，如果在给定的类中发现了大量的错误。这可能是自由裁量权有用的地方 - 仅针对可能重新发生的错误或重新发生会导致严重问题的错误添加单元测试。我发现单元测试中的集成测试测量在这些场景中会有所帮助 - 测试代码路径更高的代码可以覆盖更低的代码路径。

Answer 3

一切都应尽可能简单，但并不简单。 - A.爱因斯坦

关于TDD最容易被误解的事情之一就是其中的第一个字。测试。这就是BDD出现的原因。因为人们并不真正理解第一个D是重要的，即Driven。我们都倾向于对测试有所了解，对设计的驱动有点关注。我想这是对你的问题的一个模糊的答案，但你应该考虑如何驱动你的代码，而不是你实际测试的; 这是Coverage工具可以帮助您的东西。设计是一个更大，更有问题的问题。