blocks|key|4177865|text|让测试首先失败的一个最大的好处是，它可以确保您的测试真正测试了您的想法。你可以在你的测试中有一些细微的bug，导致它根本不能真正测试任何东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4177866|例如，我曾经在我们的C%2B%2B代码库中看到有人签入了测试：|4177867|assertTrue(x+=+1);|code-block|syntax|javascript|4177868|显然，他们没有编程，所以测试首先失败了，因为这根本不会测试任何东西。|4177869|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

The one big advantage to making the test fail first is that it ensures that your test is really testing what you think. You can have subtle bugs in your test that cause it to not really test anything at all.

For example, I once saw in our C++ code base someone check in the test:

<pre><code>assertTrue(x = 1);
</code></pre>

Clearly they didn't program so that the test failed first, since this doesn't test anything at all.

blocks|key|3332140|text|呃...我把TDD周期理解为|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332141|3332142|先写测试，这会失败，因为代码只是一个存根|unordered-list-item|3332143|写代码让测试需要|3332144|3332145|没有义务继续编写失败的测试，第一个失败是因为没有代码来做任何事情。第一个测试的重点是决定接口！|3332146|编辑:似乎对“红-绿-重构”的口号有一些误解。根据wikipedia's+TDD+article的说法|offset|length|3332147|3332148|在测试驱动开发中，每个新特性都是从编写测试开始的。此测试不可避免地会失败，因为它是在功能实现之前编写的。|blockquote|3332149|3332150|换句话说，必须失败的测试是为了一个新的功能，而不是为了额外的覆盖率！|3332151|编辑:当然，除非你想写一个回归测试来重现一个bug！|3332152|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Test-driven_development^0|0|0|0|0|0|0|P|N|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|17|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|18|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1A|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1B|8|@]|9|@$M|1C|N|1D|1|1E]]|A|$]]|$1|O|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1G|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1I|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1J|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|Y|$Z|$5|10|11|12|A|$13|14]]]]

uh...i read the TDD cycle as

<ul>
<li>write the test first, which will fail because the code is just a stub</li>
<li>write the code so that the test passes</li>
<li>refactor as necessary</li>
</ul>

there's no obligation to keep writing tests that fail, the first one fails because there's no code to do anything. the point of the first test is to decide on the interface!

EDIT: There seems to be some misunderstanding of the "red-green-refactor" mantra. According to <a href="http://en.wikipedia.org/wiki/Test-driven_development" rel="nofollow noreferrer">wikipedia's TDD article</a>

<blockquote>In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented.</blockquote>

In other words, the must-fail test is for a new feature, not for additional coverage!

EDIT: unless you're talking about writing a regression test to reproduce a bug, of course!

blocks|key|923895|text|Hard+core+TDDers会说，你总是需要失败的测试来验证阳性测试不是假阳性，但我认为在现实中，许多开发人员都会跳过失败的测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|923896|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Hard core TDDers would say you always need a failing test to verify that a positive test isn't a false positive, but I think in reality a lot of developers skip the failing test.

blocks|key|923914|text|如果你在写一段新的代码，你先写测试，然后写代码，这意味着你第一次总是失败的测试(因为它是在一个虚拟接口上执行的)。然后，您可以多次重构，在这种情况下，您可能不需要编写额外的测试，因为您拥有的测试可能已经足够了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|923915|但是，您可能希望使用测试驱动程序方法维护一些代码；在这种情况下，您首先必须将测试编写为特征测试(根据定义，永远不会失败，因为它们是针对正常工作的接口执行的)，然后进行重构。|923916|entityMap^0|W|21|0|0|2E|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

If you are writing a new piece of code, you write the test, then the code, It means that the first time you always have a failing test (because it executed against a dummy interface).
Then you may refactor several times, and in that case you may not need to write additional tests, because the one you have may be already enough.

However, you may want to maintain some code with TDD methods; in this case, you first have to write tests as characterization tests (that by definition will never fail, because they are executed against working interfaces), then refactor.

blocks|key|3332292|text|首先编写失败的测试，然后让它们运行，有两个原因；|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332293|第一个是检查测试是否真的是在测试你写它的目的。您首先检查它是否失败，然后更改代码以使测试运行，然后检查它是否运行。这看起来很愚蠢，但我有几次为已经运行的代码添加了一个测试，后来才发现我在测试中犯了一个错误，使它始终运行。|3332294|第二个也是最重要的原因是防止你写太多的测试。测试反映了您的设计，而您的设计反映了您的需求和需求更改。当这种情况发生时，你不会想要重写很多测试。一个很好的经验法则是，每个测试都因为一个原因而失败，并且只有一个测试因为这个原因而失败。TDD试图通过对代码库中的每个测试、每个功能和每个更改重复标准的红-绿-重构循环来强制执行这一点。|3332295|但当然，规则是用来打破的。如果你首先记住为什么要制定这些规则，你就可以灵活地使用它们。例如，当您发现您有测试多个东西的测试时，您可以将其拆分。实际上，您已经编写了两个以前从未见过失败的新测试。分解代码，然后修复代码，使新的测试失败，这是一种双重检查的好方法。|3332296|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

There are two reasons for writing failing tests first and then making them run;

The first is to check if the test is actually testing what you write it for. You first check if it fails, you change the code to make the test run then you check if it runs. It seems stupid but I've had several occasions where I added a test for code that already ran to find out later that I had made a mistake in the test that made it always run.

The second and most important reason is to prevent you from writing too much tests. Tests reflect your design and your design reflects your requirements and requirements change. You don't want to have to rewrite lots of tests when this happens. A good rule of thumb is to have every test fail for only one reason and to have only one test fail for that reason. TDD tries to enforce this by repeating the standard red-green-refactor cycle for every test, every feature and every change in your code-base.

But of course rules are made to be broken. If you keep in mind why these rules are made in the first place you can be flexible with them. For example when you find that you have tests that test more than one thing you can split it up. Effectively you have written two new tests that you havent seen fail before. Breaking and then fixing your code to see your new tests fail is a good way to double check things.

blocks|key|3332338|text|除了“测试优先”开发之外，还有用TDD编写测试的原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332339|假设您的排序方法除了直接排序操作之外还有其他一些属性，例如:它验证所有的输入都是整数。您最初并不依赖于此，并且它也不在规范中，因此没有测试。|3332340|稍后，如果您决定利用这个额外的行为，您需要编写一个测试，以便其他任何人出现并重构时都不会破坏您现在依赖的这个额外的行为。|3332341|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There are reasons to write tests in TDD beyond just "test-first" development.

Suppose that your sort method has some other properties beyond the straight sorting action, eg: it validates that all of the inputs are integers. You don't initially rely on this and it's not in the spec, so there's no test.

Later, if you decide to exploit this additional behaviour, you need to write a test so that anyone else who comes along and refactors doesn't break this additional behaviour you now rely on.

blocks|key|3332374|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332375|但是如果你的代码已经解决了你想要测试的情况呢？|blockquote|3332376|3332377|这是否打破了TDD总是编写失败测试的魔咒？|3332378|3332379|是的，因为您已经打破了在编写代码之前编写测试的咒语。您可以删除代码并重新开始，或者接受从头开始工作的测试。|3332380|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|M|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|N|7|@]|8|@]|9|$]]|$1|E|3|F|4|5|6|O|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|P|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|Q|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|R|7|@]|8|@]|9|$]]]|K|$]]

<blockquote>
But what if your code already accounts for the situation you want to test?
Does this break the TDD mantra of always writing failing tests?
</blockquote>
Yes, because you've already broken the mantra of writing the test before the code. You could just delete the code and start over, or just accept the test working from the start.

blocks|key|3332423|text|简单的TDD规则:编写可能失败的测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332424|如果软件工程告诉我们什么的话，那就是你不能预测测试结果。甚至不会失败。事实上，我经常看到“新功能请求”，这些请求已经在现有软件中运行。这很常见，因为许多新功能都是对现有业务需求的直接扩展。底层的、正交的软件设计仍然有效。|3332425|也就是说，新特性“列表X必须容纳最多10项”而不是“最多5项”将需要新的测试用例。当List+X的实际实现允许2%5E32个项目时，测试将通过，但在运行新测试之前，您不能确定这一点。|3332426|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Simple TDD rule: You write tests that might fail. 

If software engineering told us anything, it's that you cannot predict test results. Not even failing. It's in fact quite common for me to see "new feature requests" which already happen to work in existing software. This is common, because many new features are straightforward extensions of existing business desires. The underlying, orthogonal software design will still work.

I.e. New feature "List X must hold up to 10 items" instead of "up to 5 items" will require a new test case. The test will pass when the actual implementation of List X allows 2^32 items, but you don't know that for sure until you run the new test.

blocks|key|4178244|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4178245|我怀疑没有人会建议我浪费时间来实现一个不稳定的排序算法，只是为了测试测试用例，然后重新实现合并排序。你多久会遇到一次类似的情况，你会怎么做？|blockquote|4178246|4178247|4178248|那就让我来推荐吧。:)|4178249|所有这些东西都是你一方面花费的时间，另一方面你减少或减轻的风险，以及你获得的理解之间的权衡。|4178250|继续假设的例子。|4178251|如果“稳定性”是一个重要的属性/特性，并且您没有通过使其失败来“测试测试”，那么您节省了做这项工作的时间，但却招致了测试是错误的并且始终是绿色的风险。|4178252|另一方面，如果你通过破坏特性并看着它失败来“测试测试”，你就降低了测试的风险。|4178253|而且，通配符是，您可能会获得一些重要的知识。例如，当试图编写一个“糟糕”的排序并导致测试失败时，您可能会更深入地考虑正在排序的类型的比较约束，并发现您使用"x==y“作为排序的等价类谓词，但实际上"!(x|4178254|所以我会说“花额外的时间让它失败，即使这意味着故意破坏系统，只是为了在屏幕上看到一个红点”，因为虽然每一个小的“转移”都会产生一些时间成本，但偶尔一个会为你节省一大笔钱(例如，测试中的一个bug意味着我从来没有测试过我的系统的最重要的属性，或者哦，我们对不等式谓词的整个设计都搞砸了)。这就像玩彩票一样，除了从长远来看，赔率对你有利；每周你花5美元买彩票，通常你会输，但每三个月你就会中1000美元的大奖。|4178255|
|4178256|4178257|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Z|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|12|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|13|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|14|7|@]|8|@]|9|$]]|$1|L|3|M|4|5|6|15|7|@]|8|@]|9|$]]|$1|N|3|O|4|5|6|16|7|@]|8|@]|9|$]]|$1|P|3|Q|4|5|6|17|7|@]|8|@]|9|$]]|$1|R|3|S|4|5|6|18|7|@]|8|@]|9|$]]|$1|T|3|U|4|5|6|19|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1A|7|@]|8|@]|9|$]]|$1|W|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]]|X|$]]

<blockquote>
 I doubt anyone would recommend I waste
 the time to implement an unstable
 sorting algorithm just to test the
 test case, then reimplement the
 merge-sort. How often do you come
 across a similar situation and what do
 you do?
</blockquote>

Let me be the one recommend it then. :)

All this stuff is trade-offs between the time you spend on the one hand, and the risks you reduce or mitigate, as well as the understanding you gain, on the other hand.

Continuing the hypothetical example...

If "stableness" is an important property/feature, and you don't "test the test" by making it fail, you save the time of doing that work, but incur risk that the test is wrong and will always be green.

If on the other hand you do "test the test" by breaking the feature and watching it fail, you reduce the risk of the test. 

And, the wildcard is, you might gain some important bit of knowledge. For example, while trying to code a 'bad' sort and get the test to fail, you might think more deeply about the comparison constraints on the type you're sorting, and discover that you were using "x==y" as the equivalence-class-predicate for sorting but in fact "!(x&lt;y) &amp;&amp; !(y&lt;x)" is the better predicate for your system (e.g. you might uncover a bug or design flaw).

So I say err on the side of 'spend the extra time to make it fail, even if that means intentionally breaking the system just to get a red dot on the screen for a moment', because while each of these little "diversions" incurs some time cost, every once in a while one will save you a huge bundle (e.g. oops, a bug in the test means that I was never testing the most important property of my system, or oops, our whole design for inequality predicates is messed up). It's like playing the lottery, except the odds are in your favor in the long run; every week you spend $5 on tickets and usually you lose but once every three months you win a $1000 jackpot.

blocks|key|114688|text|您提供的示例是编写通过第一次尝试的测试的合适时机之一。正确测试的目的是记录系统的预期行为。可以在不更改实现的情况下编写测试，以进一步阐明预期行为是什么。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|114689|附注：|114690|据我所知，以下是您希望测试在通过之前失败的原因：|114691|你“写一个你知道会失败的测试，但在它通过之前测试它”的原因是，每隔一段时间，最初认为测试肯定会失败的假设是错误的。在这些情况下，测试现在使您不必编写不必要的代码。|114692|entityMap^0|14|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|S|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|M|$]]

The example you provided is IMO one of the proper times to write a test that passes first try. The purpose of proper tests is to document the expected behavior of the system. It's ok to write a test without changing the implementation to further clarify what the expected behavior is.

P.S.

As I understand it, here's the reason you want the test to fail before making it pass:

The reason you "write a test that you know will fail, but test it before making it pass" is that every once in a while, the original assumption that the test will surely fail is wrong. In those cases the test has now saved you from writing unnecessary code.

blocks|key|924082|text|这种情况我已经遇到过很多次了。虽然我推荐并尝试使用TDD，但有时它会使流程中断太多，无法停止并编写测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|924083|我有一个两步解决方案：|924084|924085|一旦您有了可以工作的代码和未失败的测试，就故意在代码中插入更改以导致测试失败。|ordered-list-item|924086|将更改从原始代码中剪切出来，并将其放在注释中-或者放在代码方法中，或者放在测试方法中，这样下次有人想要确保测试仍然可以检测到失败时，他们知道该怎么做。这也可以作为您已经确认测试获得失败的事实的证明。如果它是最干净的，那么就把它留在code方法中。您甚至可能希望使用条件编译来启用测试断路器。|924087|924088|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

I have run into this situation many times. Whilst I recommend and try to use TDD, sometimes it breaks the flow too much to stop and write tests.

I have a two-step solution:

<ol>
<li>Once you have your working code and your non-failing test, deliberately insert a change into the code to cause the test to fail.</li>
<li>Cut that change out of your original code and put it in a comment - either in the code method or in the test method, so next time someone wants to be sure the test is still picking up failures they know what to do. This also serves as your proof of the fact that you have confirmed the test picks up failure. If it is cleanest, leave it in the code method. You might even want to take this so far as to use conditional compilation to enable test breakers.</li>
</ol>

blocks|key|3332719|text|正如其他人所说，TDD的口号是“没有失败的单元测试就没有新的代码”。我从来没有听过任何TDD从业者说过“没有代码就没有新的测试”。新的测试总是受欢迎的，即使它们“碰巧”“意外”通过。没有必要将代码更改为中断，然后再将其更改回来以通过测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332720|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As others have said, the mantra of TDD is "no new code without a failing unit test". I have never heard any TDD practitioners say "no new tests without missing code". New tests are always welcome, even if they "happen" to "accidentally" pass. There's no need to change your code to break, then change it back to pass the test.

From what I understand, in TDD you have to write a failing test first, then write the code to make it pass, then refactor. But what if your code already accounts for the situation you want to test?

For example, lets say I'm TDD'ing a sorting algorithm (this is just hypothetical). I might write unit tests for a couple of cases: 

input = 1, 2, 3 
output = 1, 2, 3
 
 
input = 4, 1, 3, 2 
output = 1, 2, 3, 4
 
etc...

To make the tests pass, I wind up using a quick 'n dirty bubble-sort. Then I refactor and replace it with the more efficient merge-sort algorithm. Later, I realize that we need it to be a stable sort, so I write a test for that too. Of course, the test will never fail because merge-sort is a stable sorting algorithm! Regardless, I still need this test incase someone refactors it again to use a different, possibly unstable sorting algorithm. 

Does this break the TDD mantra of always writing failing tests? I doubt anyone would recommend I waste the time to implement an unstable sorting algorithm just to test the test case, then reimplement the merge-sort. How often do you come across a similar situation and what do you do?

TDD - When is it okay to write a non-failing test?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

据我所知，在TDD中，你必须先写一个失败的测试，然后写代码让它通过，然后重构。但是，如果您的代码已经考虑到了您想要测试的情况，该怎么办？例如，假设我正在测试一个排序算法(这只是一个假设)。我可能会为几种情况编写单元测试：输入= 1、2、3输出= 1、2、3输入= 4、1、3、2输出= 1、2、3、4等等。为了通过测试，...

问TDD -什么时候可以写一个不失败的测试？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问TDD -什么时候可以写一个不失败的测试？EN