The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
在我阅读关于测试驱动开发（TDD）的一篇之前的文章时，我读了很多博客文章和几本书，发现我对其中的一些观点持不同意见，甚至有一些观点是相当重要的。似乎大多数软件专家对软件开发的工作方式存在误解。也许是因为他们并不是真正的程序员，而是书籍作者和会议演讲者。
Robert Martin（@unclebobmartin）在《TDD的周期》一文中：
I disagree. This statement goes against the very philosophy of testing: “a passing test is a weak test.” Unfortunately, a traditional understanding of testing is quite the opposite: tests must pass to make us happy. Thus, if we keep thinking about how to make our future tests pass we will shoot ourselves in the foot: tests will pass and the code quality will go down. Instead, we must design our code in a way that makes it easy to break with the future tests. The code must help its tests to break it! Because a test that is easy to make “red” is a good test. A test that is always “green” is a useless test. Uncle Bob, I’m sure, is aware of that.
James Shore（@jamesshore）在Red-Green-Refactor（2005年11月）中提到：
I disagree. I have nothing against the first two steps: 1) the test is “red” because it doesn’t pass, and 2) the test is “green” when the code is fixed and passes. I disagree that refactoring is a responsibility of the person who fixes the test. If the code needs refactoring, it’s a bug, just like any other bug, either functional or design. It has to be reported, assigned and paid for. We must not do any code modifications, no matter how good our intentions are, if they are not required and paid for. Refactoring after fixing the test is a frivolous violation of management and coordination structure in a project.
Robert Martin（@unclebobmartin）在当TDD不起作用时（2014年4月）中提到：
I disagree. Test Doubles (also known as fake objects) are the tools that help us find our where the code is broken. If the tool is unreliable, how can we test our code against it? This reminds me of an old joke where a patient comes to the doctor and says “Help me doc, my body hurts anywhere I touch it with my finger!” The doctor answers “It’s just your finger—it’s broken!” A very similar situation occurs here: If we test our production objects with broken Test Doubles, they will all look broken.
大卫·海内迈尔·汉森（@dhh）在像TSA一样进行测试（2012年四月）中说：
I disagree. I don’t know exactly what units of measurement were used to compare the “code” and the “test,” but I can only assume Lines-of-Code. I was curious and decided to calculate this ratio in a few projects of mine. First, I tried jcabi-github, an immutable GitHub Java API client. The numbers were: 9.8K LoC in production classes, 6.2K in built-in fake classes, and 16.2K in test classes. Thus, the ratio was 9.8 to 22.4, which meant 1:2.3. Somewhere between a “smell” and a “stink,” according to David. Then I calculated the ratio for a few other projects of mine: jcabi-http (1:1), xembly (1:0.92), takes (1:0.91), and rultor (1:0.6). It seems that the higher the ratio the higher my confidence in the product’s quality. Thus, I don’t think that it’s a smell or a stink. Instead, in a yummy-scented product the amount of test code is a few times larger than its production counterpart.
肯特·贝克（@kentbeck）在《你的单元测试有多深入？》（2008年9月）一文中提到。
I disagree. Tests are not a separate product which either we are paid for or not. Tests are part of the code. An instrument of its development, maintenance and validation. Tests are similar to, say, file names. We don’t write our code naming all the files 1.java, 2.java, 234.java, and then say: “Now you pay me so that I can rename them properly.” That would be weird, right? That’s how the statement “I’m not paid for writing tests” sounds to me: weird. Do we really have to be paid to name files correctly? We just do it, because it’s convenient for us. Because proper self-descriptive file names make our code more readable and maintainable. It’s impossible to imagine a modern maintainable code base without tests. I would actually suggest changing that phrase to: “I get paid for code that is tested, not just for code.”
What do you do if a customer says: "I won't pay for unit tests?" #codeahead
— Yegor Bugayenko (@yegor256) July 14, 2019
我会持续更新这篇文章。如果你知道一篇关于TDD的“好”文章，请把它发给我；也许我会从中找到一些有趣的引用。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 04:43
