问题描述
我发现关于 TDD 的一点是它需要时间来设置您的测试并且我天生懒惰，我总是想编写尽可能少的代码.我似乎做的第一件事是测试我的构造函数是否设置了所有属性，但这是否太过分了?
The thing I've found about TDD is that its takes time to get your tests set up and being naturally lazy I always want to write as little code as possible. The first thing I seem do is test my constructor has set all the properties but is this overkill?
我的问题是您编写单元测试的粒度级别是多少?
My question is to what level of granularity do you write you unit tests at?
..是否有测试过多的情况?
..and is there a case of testing too much?
推荐答案
我为有效的代码而不是测试获得报酬，所以我的理念是尽可能少地测试以达到给定的信心水平(我怀疑这与行业标准相比，信心水平很高，但这可能只是狂妄自大).如果我通常不会犯某种错误(例如在构造函数中设置错误的变量)，我不会对其进行测试.我确实倾向于理解测试错误，所以当我有复杂条件的逻辑时，我会格外小心.在团队中编码时，我会修改我的策略以仔细测试我们共同容易出错的代码.
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong.
基于这种理念，不同的人会有不同的测试策略，但鉴于对测试如何最好地融入编码的内部循环的理解尚不成熟，这对我来说似乎是合理的.从现在起 10 或 20 年后，我们可能会有一个更普遍的理论，关于编写哪些测试，不编写哪些测试以及如何区分差异.与此同时，实验似乎有条不紊.
Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we'll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order.
这篇关于你的单元测试有多深?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！