blocks|key|325711|text|在我看来，最好是用“代码优先，测试后”的50%25测试覆盖率和100%25完成库，而不是100%25的测试覆盖率和50%25完成库的TDD。过一段时间后，您的开发伙伴将有希望发现为他们编写的所有public代码编写测试是一件有趣且有教育意义的事情，因此测试驱动程序将悄悄进入他们的开发例程。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|325712|entityMap^0|2H|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

It's in my humble opinion better to have 50% test coverage with "code first, test after" and a 100% completed library, than 100% test coverage and a 50% completed library with TDD. After a while, your fellow developers will hopefully find it entertaining and educational to write tests for all of the <code>public</code> code they write, so TDD will sneak its way into their development routine.

blocks|key|3078560|text|在编写代码之后，编写单元测试绝对是值得的。只是有时候它通常更难，因为你的代码不是被设计成可测试的，你可能把它变得过于复杂了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3078561|我认为，将团队引入TDD的一个很好的务实方法是在过渡期或长期提供另一种“在开发期间进行测试”的方法。应该鼓励他们使用TDD代码中对他们来说很自然的部分。然而，在看起来很难以测试为主的代码部分中，或者在使用由非敏捷A&D过程预先确定的对象时，开发人员可以选择编写一小部分代码，然后编写覆盖该代码的测试，并重复此过程。在编写代码之后立即为某些代码编写单元测试，总比根本不编写单元测试要好。|3078562|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It is absolutely still worth writing the unit tests after code is written. It's just that sometimes it's often harder because your code wasn't designed to be testable, and you may have overcomplicated it.

I think a good pragmatic way to bring a team into TDD is to provide the alternative method of "test-during development" in the transition period, or possibly in the long-term. They should be encouraged to TDD sections of code that seem natural to them. However, in sections of code that seem difficult to approach test-first or when using objects that are predetermined by a non-agile A&amp;D process, developers can be given the option of writing a small section of the code, then writing tests to cover that code, and repeating this process. Writing unit tests for some code immediately after writing that code is better than not writing any unit tests at all.

blocks|key|3291984|text|如果团队在实现测试驱动开发方面举步维艰，但他们没有创建任何单元测试before...then，那么就在编写代码后创建单元测试。即使是在代码之后编写的单元测试也比根本没有单元测试要好！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3291985|一旦他们精通单元测试(以及随之而来的一切)，您就可以让他们第二次创建测试first...and代码。|3291986|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If the team is floundering at implementing TDD, but they weren't creating any Unit Tests before...then start them off by creating Unit Tests after their code is written. Even Unit tests written after the code are better than no Unit Tests at all!

Once they're proficient at Unit Testing (and everything that comes with it), then you can work on getting them to create the tests first...and code second.

blocks|key|3291991|text|我只是在日历上读到这样一句话：“每条规则，执行到极致，都会变得荒谬甚至危险。”所以我的建议是不要对它信教。您的团队中的每个成员都必须在测试时他们觉得“正确”的东西之间找到平衡。这样，团队中的每个成员都将是最有效率的(而不是问“为什么我必须写这个sti*测试？？”)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3291992|因此，一些测试总比没有好，代码后测试比几个测试好，代码前测试比代码后测试好。但是每一步都有它自己的优点，你不应该皱眉，即使是很小的一步。|3291993|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I just read this on a calendar: "Every rule, executed to its utmost, becomes ridiculous or even dangerous." So my suggestion is not to be religious about it. Every member of your team must find a balance between what they feel "right" when it comes to testing. This way, every member of your team will be most productive (instead of, say, thinking "why do I have to write this sti**** test??").

So some tests are better than none, tests after the code are better than few tests and testing before the code is better than after. But each step has its own merits and you shouldn't frown upon even small steps.

blocks|key|327999|text|好吧，如果你不先写测试，那就不是“测试驱动”，它只是测试。它本身有好处，如果你已经有了代码库，那么为它添加测试肯定是很有用的，即使它不是TDD，而仅仅是测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|328000|首先编写测试是关于在编写代码之前关注代码应该做什么。是的，这样做你也会得到测试，这很好，但有些人可能会认为这甚至不是最重要的一点。|328001|我要做的就是使用测试驱动开发对团队进行toy+projects+like+these+(参见Coding+Dojo，Katas)的培训(如果你能得到有经验的测试驱动开发程序员参加这样的研讨会，那就更好了)。当他们看到好处时，他们将在实际项目中使用TDD。但同时不要强迫他们，如果他们看不到好处，他们就不会做正确的事情。|offset|length|328002|entityMap|0|LINK|mutability|MUTABLE|url|http://sites.google.com/site/tddproblems/^0|0|0|J|N|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Well, if you do not write tests firsts it's not "Test Driven", it's just testing. It has benefits in itself and if you allready have a code base adding tests for it is certainly usefull even if it's not TDD but merely testing.

Writing tests first is about focusing on what the code should do before writing it. Yes you also get a test doing that and it's good, but some may argue it's not even the most important point.

What I would do is train the team on <a href="http://sites.google.com/site/tddproblems/" rel="nofollow noreferrer">toy projects like these</a> (see Coding Dojo, Katas) using TDD (if you can get experienced TDD programmers to participate in such workshop it would be even better). When they'll see the benefits they will use TDD for the real project. But meanwhile do not force them, it they do not see the benefit they won't do it right.

blocks|key|3078616|text|如果他们是测试的新手，那么就开始测试已经编写好的代码，然后慢慢过渡到先编写测试。作为一个尝试学习TDD和单元测试新手的人，我发现很难做一个完整的180，并改变我的思维定势，在编写代码之前编写测试，所以我采取的方法是50-50的混合；当我确切知道代码看起来是什么样子时，我会编写代码，然后编写测试来验证它。对于我不能完全确定的情况，我将从测试开始，然后向后工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3078617|还要记住，编写测试来验证代码，而不是编写代码来满足测试并没有错。如果你的团队不想走TDD路线，那么不要强迫他们这样做。|3078618|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If they're new to testing than IMO start off testing code that's already been written and slowly graduate to writing tests first. As someone trying to learn TDD and new to unit testing, I've found it kind of hard to do a complete 180 and change my mindset to write tests before code, so the approach I'm taking is sort of a 50-50 mix; when I know exactly what the code will look like, I'll write the code and then write a test to verify it. For situations where I'm not entirely sure then I'll start with a test and work my way backwards.

Also remember that there is nothing wrong with writing tests to verify code, instead of writing code to satisfy tests. If your team doesn't want to go the TDD route then don't force it on them.

blocks|key|323284|text|TDD是关于设计的！因此，如果您使用它，您将确保您的代码具有可测试的设计，从而使编写测试变得更容易。如果你在代码写好之后再写测试，它们仍然是有价值的，但是我想你是在浪费时间，因为你可能不会有一个可测试的设计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323285|我可以给你一个建议，试图说服你的团队采用测试驱动开发，那就是使用Fearless+Change:+Patterns+for+Introducing+New+Ideas,+by+Mary+Lynn+Manns+and+Linda+Rising中描述的一些技术。|offset|length|323286|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0201741571^0|0|W|2G|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

TDD is about design! So if you use it, you will be sure to have a testable design of your code, making it easier to write your tests. If you write tests after the code is written they are still valuable but IMHO you will be wasting time since you will probably not have a testable design.

One suggestion I can give to you to try to convince your team to adopt TDD is using some of the techniques described in <a href="https://rads.stackoverflow.com/amzn/click/com/0201741571" rel="nofollow noreferrer" rel="nofollow noreferrer">Fearless Change: Patterns for Introducing New Ideas, by Mary Lynn Manns and Linda Rising</a>.

blocks|key|3078691|text|开始构建JUnit测试类是开始的方法，对于现有代码来说这是唯一的开始。根据我的经验，为现有代码创建测试类非常有用。如果管理层认为这会花费太多时间，您可以建议仅在发现相应的类包含错误或需要清理时才编写测试类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3078692|对于维护过程，让团队越过这条线的方法是编写JUnit测试，以便在修复错误之前重现它们。|3078693|3078694|bug+is+reported|unordered-list-item|3078695|create+JUnit测试类如果需要，请添加修复代码错误的测试|3078696|3078697|3078698|运行测试以显示当前代码不会重现错误|3078699|<代码>F211|3078700|您可以解释说，通过以这种方式“记录”bug，可以防止这些bug在以后再次出现。这是团队可以立即体验到的好处。|3078701|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|G|7|Y|8|@]|9|@]|A|$]]|$1|K|3|-4|5|G|7|Z|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|10|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|11|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|12|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|S|$]]

Starting to build JUnit test classes is the way to start, for existing code it's the only way to start. In my experience it is very usefull to create test classes for existing code. If management thinks this will invest too much time, you can propose to only write test classes when the corresponding class is found to contain a bug, or is in need of cleanup.

For the maintenance process the approach to get the team over the line would be to write JUnit tests to reproduce bugs before you fix them, i.e.

<ul>
<li>bug is reported</li>
<li>create JUnit test class if needed</li>
<li>add a test that reproduces the bug</li>
<li>fix your code</li>
<li>run the test to show the current code does not reproduce the bug</li>
</ul>

You can explain that by "documenting" bugs in this way will prevent those bugs from creeping back in later. That is a benefit the team can experience immediately.

blocks|key|3292146|text|单元测试最有用的方面之一是确保已经在工作的代码的持续正确性。当您可以随意重构时，让IDE提醒您编译时错误，然后单击一个按钮让您的测试发现任何潜在的运行时错误--有时会出现以前微不足道的代码块，然后我想您会发现您的团队开始欣赏TDD了。因此，从测试现有代码开始绝对是有用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3292147|另外，坦率地说，我学到了更多关于如何通过尝试测试编写的代码来编写可测试代码的知识，而不是从TDD开始。如果您试图考虑既能实现最终目标又能进行测试的契约，那么一开始就太抽象了。但是，当您查看代码时，您可能会说“这里的单例完全破坏了依赖注入，并使测试变得不可能”，您开始理解是什么模式使您的测试工作变得更容易。|3292148|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One of the most useful aspect of unit testing is ensuring the continuing correctness of already working code. When you can refactor at will, let an IDE remind you of compile time errors, and then click a button to let your tests spot any potential runtime errors--sometimes arriving in previously trivial blocks of code, then I think you will find your team starting to appreciate TDD. So starting with testing existing code is definitely useful.

Also, to be blunt, I have learned more about how to write testable code by trying to test written code than from starting with TDD. It can be too abstract at first if you are trying to think of contracts that will both accomplish the end goal and allow testing. But when you look at code and can say "This singleton here completely spoils dependency injection and makes testing this impossible," you start to develop an appreciation for what patterns make your testing life easier.

blocks|key|325116|text|这是你的团队在开始相信它之前必须取得自己的成功的东西。对于任何关心我的nUnit顿悟的人，我都会大喊大叫：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325117|大约5年前，我在一个项目中发现了nUnit。我们几乎完成了V1.0，我创建了一些测试，只是为了尝试这个新工具。我们有很多bug(显然！)因为我们是一个新团队，期限很紧，期望很高(听起来很熟悉？)等等。不管怎么说，我们从1.0版本开始，从1.1版本开始。我们对团队进行了一些调整，我得到了两个开发人员分配给我。我为他们做了一个1小时的演示，告诉他们我们写的每一件事都必须有一个测试用例。在1.1开发周期中，我们经常“落后于”团队的其他成员，因为我们编写了更多的代码，单元测试。我们最终做了更多的工作，但这是回报--当我们最终进入测试时，我们的代码中恰好没有bug。我们帮助其他所有人调试和修复他们的bug。在验尸报告中，当bug计数出现时，它引起了所有人的注意。|325118|我不会愚蠢到认为你可以测试你的成功之路，但我是一个真正的单元测试的信徒。该项目采用了nUnit，由于1个成功，它很快就传播到了所有.Net项目的公司。我们发布V1.1的总时间是9个开发周，所以它肯定不是一夜之间就成功的。但从长远来看，它对我们的项目和我们为之构建解决方案的公司来说是成功的。|325119|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|$]]

This is something that your team will have to have its own successes with before they begin to believe it in. I'll rant about my nUnit epiphany for anyone who cares:

About 5 years ago I discovered nUnit when working on a project. We had almost completed V1.0 and I created a few tests just to try out this new tool. We had a lot of bugs (obviously!) because we were a new team, on a tight deadline, high expectations (sound familiar?) etc. Anyway we got 1.0 in and started on 1.1. We re-orged the team a little bit and I got 2 devs assigned to me. I did a 1-hour demo for them and told them that everything we wrote had to have a test case with it. We constantly ran "behind" the rest of the team during the 1.1 dev cycle because we were writing more code, the unit tests. We ended up working more but here's the payoff -- when we finally got into testing we had exactly 0 bugs in our code. We helped everyone else debug and repair their bugs. In the postmortem, when the bug counts showed up, it got EVERYONE's attention.

I'm not dumb enough to think you can test your way to success but I am a true believer when it comes to unit tests. The project adopted nUnit and it soon spread to the company for all .Net projects as a result of 1 success. Total time period for our V1.1 release was 9 dev weeks so it was definitely NOT an overnight success. But long term, it proved successful for our project and the company we built solutions for.

blocks|key|325124|text|毫无疑问，测试(首先、同时甚至是之后)将节省您的精力，并提高您的工作效率和信心。我推荐采用它！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325125|我处于类似的情况，因为我是一个“菜鸟”开发人员，当我在团队项目中工作时，我经常因为一个贡献破坏了构建的事实而感到沮丧。我不知道是不是该怪我，甚至在某些情况下，该怪谁。但我更担心的是，我对我的开发伙伴做了同样的事情。这种认识促使人们采用了一些TDD策略。我们的团队开始有一些愚蠢的游戏和规则，比如你在所有测试通过之前不能回家，或者如果你提交了一些没有测试的东西，那么你必须给每个人买“啤酒/午餐/等等”，这让TDD变得更有趣。|325126|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

There is no doubt that testing (First, While or even After) will save your bacon, and improve your productivity and confidence. I recommend adopting it! 

I was in a similar situation, because I was a "noob" developer, I was often frustrated when working on team project by the fact that a contribution had broken the build. I did not know if I was to blame or even in some cases, who to blame. But I was more concerned that I was doing to same thing to my fellow developers. This realisation then motivated to adopt some TDD strategies. Our team started have silly games, and rules, like you cannot go home till all your tests pass, or if you submit something without a test, then you have to buy everyone "beer/lunch/etc" and it made TDD more fun.

blocks|key|3292191|text|TDD是一种开发人员可以用来生成更好代码的工具。我碰巧觉得编写可测试代码的练习至少和测试本身一样有价值。为了测试目的而隔离IUT+(在测试下的实现)有一个副作用，那就是解耦代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3292192|TDD并不适合每个人，也没有什么魔力可以让团队选择这样做。风险在于，不知道什么值得测试的单元测试编写者将编写大量低价值测试，这将成为组织中TDD怀疑论者的炮灰。|3292193|我通常使自动化验收测试没有商量余地，但允许开发人员采用适合他们的TDD。我有我的经验丰富的TDDers培训/导师，其余的，并在许多个月的时间里通过例子“证明”其有用性。|3292194|这既是一种技术变化，也是一种社会/文化变化。|3292195|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|$]]

TDD is a tool that developers can use to produce better code. I happen to feel that the exercise of writing testable code is as least as valuable as the tests themselves. Isolating the IUT (Implementation Under Test) for testing purposes has the side affect of decoupling your code.

TDD isn't for everyone, and there's no magic that will get a team to choose to do it. The risk is that unit test writers that don't know what's worth testing will write a lot of low value tests, which will be cannon fodder for the TDD skeptics in your organization.

I usually make automated Acceptance Tests non-negotiable, but allow developers to adopt TDD as it suits them. I have my experienced TDDers train/mentor the rest and "prove" the usefulness by example over a period of many months.

This is as much a social/cultural change as it is a technical one.

blocks|key|3292206|text|我在许多组织中都这样做过，我发现启动和遵循TDD的最好方法就是建立结对编程。如果你有其他了解TDD的人，那么你们两个可以分开，并与其他开发人员结对使用TDD进行一些配对编程。如果没有，我会先培训一些人来帮助你完成这项工作，然后再将其介绍给团队的其他成员。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3292207|单元测试，特别是TDD的一个主要障碍是开发人员不知道如何做，所以他们不知道如何值得他们的时间。而且，当你第一次开始的时候，它的速度要慢得多，而且似乎没有提供任何好处。只有当你擅长它时，它才能真正为你提供好处。通过设置成对的编程会话，您可以快速地让开发人员能够快速学习并更快地掌握它。此外，当你们一起工作时，他们将能够立即看到它的好处。|3292208|在过去，这种方法对我来说已经成功过很多次。|3292209|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|$]]

I have done this in many organizations and I have found the single best way to get TDD started and followed is to set up pair programming. If you have someone else you can count on that knows TDD then the two of you can split up and pair with other developers to actually do some paired programming using TDD. If not I would train someone who will help you to do this before presenting it to the rest of the team.

One of the major hurdles with unit testing and especially TDD is that developers don't know how to do it, so they can not see how it can be worth their time. Also when you first start out, it is much slower and doesn't seem to provide benefits. It is only really providing you benefits when you are good at it. By setting up paired programming sessions you can quickly get developers to be able to learn it quickly and get good at it quicker. Additionally they will be able to see immediate benefits from it as you work though it together.

This approach has worked many times for me in the past.

blocks|key|3292403|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3292404|一旦编写好代码，我可能会成功地让团队编写单元测试(也许作为签入代码的要求)，我的假设是，编写这些单元测试仍然是有价值的。|blockquote|3292405|3292406|3292407|毫无疑问，单元测试的代码是有价值的(无论测试是什么时候编写的)，我在“完成的定义”中包含了“代码是单元测试的”。人们可以使用TDD或不使用TDD，只要他们进行测试。|3292408|关于版本控制，我喜欢使用带有单元测试策略的“开发分支”(即编译和构建代码，所有单元测试都通过)。完成功能后，它们将从开发分支发布到主干。换句话说，主干分支就是“完成分支”(主干上没有垃圾！)并且有一个shippable策略(可以在任何时候发布)，它比“单元测试”更严格，包括更多的东西。|offset|length|style|BOLD|3292409|entityMap^0|0|0|0|0|0|E|4|2S|9|0^^$0|@$1|2|3|-4|4|5|6|P|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Q|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|R|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|T|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|U|7|@$J|V|K|W|L|M]|$J|X|K|Y|L|M]]|8|@]|9|$]]|$1|N|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]]|O|$]]

<blockquote>
 I can probably succeed in getting the team to write unit tests once the code is written (perhaps as a requirement for checking in code) and my assumption is that there is still value in writing those unit tests. 
</blockquote>

There is absolutely no doubt about the fact that there is value in unit tested code (regardless of when tests were written) and I include "the code is unit tested" in the "Definition of Done". People may use TDD or not, as long as they test.

Regarding version control, I like to use "development branches" with a unit tested policy (i.e. the code compiles and builds, all unit tests pass). When features are done, they are published from development branches to the trunk. In other words, the trunk branch is the "Done branch" (No junk on the trunk!) and has a shippable policy (can release at any time) which is more strict and includes more things than "unit tested".

blocks|key|325905|text|发现TDD好处的一种有效方法是对一些现有功能进行重大重写，这可能是出于性能原因。通过创建一套能够很好地覆盖现有代码的所有功能的测试，这将使您有信心重构为您的核心内容，并且完全相信您的更改是安全的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325906|请注意，在这种情况下，我讨论的是测试设计或合同单元测试，这些测试实现的细节在这里并不合适。但话又说回来，TDD不能根据定义测试实现，因为它们应该在实现之前编写。|325907|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

One powerful way to discover the benefits of TDD is to do a significant rewrite of some existing functionality, perhaps for performance reasons. By creating a suite of tests that do a good job covering all the functionality of the existing code, this then gives you the confidence to refactor to your heart's content with full confidence that your changes are safe. 

Note that in this case I'm talking about testing the design or contract - unit tests that test implementation details will not be suitable here. But then again, TDD can't test implementation by definition, as they are supposed to be written before the implementation.

blocks|key|3292438|text|如果您在编写代码之前有设计会话，或者必须生成设计文档，那么您可以添加Unit+Tests作为会话的有形结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3292439|然后，这可以作为代码应该如何工作的规范。鼓励在设计会议上结对，让人们讨论一些东西应该如何工作，以及它在给定的场景下应该做什么。边缘情况是什么，有明确的测试用例，这样每个人都知道如果给出一个空参数，它会做什么。|3292440|顺便说一句，BDD也可能会引起人们的兴趣|offset|length|3292441|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Behavior_Driven_Development^0|0|0|6|3|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

If you have design sessions before writing code or have to produce a design doc, then you could add Unit Tests as the tangible outcome of a session. 

This could then serve as a specification as to how your code should work. Encourage pairing on the design session, to get people talking about how something should work and what it should do in given scenarios. What are the edge cases, with explicit test cases for them so everyone knows what it's going to do if given a null argument for example.

An aside but <a href="http://en.wikipedia.org/wiki/Behavior_Driven_Development" rel="nofollow noreferrer">BDD</a> also may be of interest

blocks|key|3292447|text|您可能会通过展示一两个TDD导致编写的代码较少的示例来发现一些吸引力-因为您只编写通过测试所需的代码，所以更容易抵制金盘或参与YAGNI的诱惑。你不需要编写的代码不需要维护、重构等，所以这是一个“真正的节省”，可以帮助销售TDD的概念。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3292448|如果你能清楚地证明它在时间、成本、代码和bug方面的价值，你可能会发现它更容易推销。|3292449|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You may find some traction by showing an example or two where TDD results in less code being written - because you only write code required to make the test pass, the temptation to gold-plate or engage in YAGNI is easier to resist. Code you don't write doesn't need to be maintained, refactored, etc, so it's a "real savings" that can help sell the concept of TDD.

If you can clearly demonstrate the value in terms of time, cost, code and bugs saved, you may find it's an easier sell.

My company is fairly new to unit testing our code. I've been reading about TDD and unit testing for some time and am convinced of their value. I've attempted to convince our team that TDD is worth the effort of learning and changing our mindsets on how we program but it is a struggle. Which brings me to my question(s).

There are many in the TDD community who are very religious about writing the test and then the code (and I'm with them), but for a team that is struggling with TDD does a compromise still bring added benefits? 

I can probably succeed in getting the team to write unit tests once the code is written (perhaps as a requirement for checking in code) and my assumption is that there is still value in writing those unit tests. 

What's the best way to bring a struggling team into TDD? And failing that is it still worth writing unit tests even if it is after the code is written?

EDIT

What I've taken away from this is that it is important for us to start unit testing, somewhere in the coding process. For those in the team who pickup the concept, start to move more towards TDD and testing first. Thanks for everyone's input.

FOLLOW UP

We recently started a new small project and a small portion of the team used TDD, the rest wrote unit tests after the code. After we wrapped up the coding portion of the project, those writing unit tests after the code were surprised to see the TDD coders already done and with more solid code. It was a good way to win over the skeptics. We still have a lot of growing pains ahead, but the battle of wills appears to be over. Thanks for everyone who offered advice!

TDD vs. Unit testing

单元测试

验收测试

我的公司对我们的代码进行单元测试还是个新手。我读到TDD和单元测试已经有一段时间了，我相信它们的价值。我试图说服我们的团队，TDD是值得我们努力学习和改变我们如何编程的心态的，但这是一场斗争。这就引出了我的问题。在TDD社区中有许多人非常热衷于编写测试和代码(我和他们一样)，但是对于一个正在为TDD而苦苦挣扎的团队来说...

问TDD与单元测试
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问TDD与单元测试EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问TDD与单元测试
EN