I felt the need to expand on this, as everyone else seems to just want to give you their opinion of TDD and not help you on your quest to become a Jedi-Ninja. The Michael Jordan of TDD is Kent Beck. He really did write the book on it:
All are great people to follow. You should also consider attending some conferences like Agile 2010, or Software Craftsmanship (this year they were held at the same time in Chicago)
I don't like it when people say "Practice X is never bad; if it doesn't work, you're not doing it right." Sorry, it has the same feel as any other over-zealous religious dogma. I don't buy it.
I agree with those folks who say that the best solution your time and money can afford should be the goal.
Anyone who objects to TDD should not automatically be accused of disregarding quality. ("So when did you stop beating your wife?") The fact is that software has bugs in it, and the cost of eliminating all of them has to be weighed against the benefit.
The same holds true in manufacturing. Tolerances on dimensions and finishes on surfaces are not all the same, because sometimes a close tolerance and a mirror finish aren't warranted.
Yes, I write unit tests, although not often before I write the class. I've seen the effect of tests on design. I measure and watch code coverage. If I find that my coverage isn't acceptable, I write more tests. I understand the benefit of a safety net of unit tests for refactoring. I follow those practices even when I'm working alone, because I've experienced the benefits first-hand. I get it.
But I'd look askance at any teammate that started bugging me about "eating, sleeping, and breathing unit testing and TDD."
My manager says that the only way that will get me a promotion is if I can get the team to TDD/BDD.
Ever think that maybe this makes you sound like a suck-up? Have you found that your nagging has alienated the rest of your team?
This response might lose me a few reputation points, but it had to be said.
I think a better approach would be to practice it yourself and let others see the benefit. Lead by example. It'll be far more persuasive than running your mouth.
Geez, Grails has test generation built-in. If you're working on a team that uses Grails, how much more selling is needed?
Best practice IMHO: Do what is practical and not just because it is a process. Don't forget what the goal of writing applications is, and in the business world, it isn't writing tests. Don't get me wrong, they have their place, but that shouldn't be the goal.
Metrics are, IMHO, the best way to get from here to there. Keep track of how well your code is covered, keep deltas of code complexity for every commit, use test-runners that watch your code for changes and constantly re-run the corresponding tests. Never let test lengths get above a few lines, so that all your tools work well. And I'd recommend once a month, take a day off to run your code through a mutation tester. That day should be dedicated to writing tests only. All of this stuff will bring you pain if you're not already doing good TDD. Learn from the pain, and in no time at all, you'll be doing it right.
And never lose sight of what the tests are for: To describe desired behavior. They are your executable specification. (This is also why I like Cucumber; now you can get your PHB to write your tests for you! Well, maybe not quite that good, but it's close!)
阅读 Kent Beck 的有关测试驱动设计的书。从测试开始，然后编写代码。获取运行测试的构建服务器！您不需要为整个团队提供它 - 为自己做，并向他们展示这有帮助。
说教只会惹恼当地人:)
"PS: My manager says that the only way that will get me a promotion is if I can get the team to TDD/BDD."
The only realistic way to get a team to do something (without killing you in the process) is to demonstrate to them clearly that it will benefit them to change their habits. In other words, write code. Lots of code. Tons of code. And then when the crucial email arrive that alters the specification radically, show them that you can change your code easily with refactoring and whats worse because you were prepared for it with your tests in place. The bar was green, hack hack hack, RED BAR!!!!, hack hack hack, green bar, go home.
Read Kent Becks book about test driven design. Start with tests and then do the code. Get a build server running which RUNS THE TESTS! You do not need ot have it for the whole team - do it for yourself and SHOW them that it helps.
《干净的代码：敏捷软件工艺手册》 作者：Robert C. Martin；如果 Kent Beck 描述了 TDD 的如何，那么 Bob 叔叔则描述了原因。
I've been doing TDD for a couple of years, but lately I've started looking more in to the BDD way of driving my design and development. Resources that helped me get started on BDD was first and formost Dan North's blog (the 'founder' of BDD). Take a look at Introducing BDD. There's also an 'official' BDD Wiki over at behaviour-driven.org with some good post well worth reading.
The one thing that I found really hard when starting out with BDD (and still find a bit hard) is how to formulate those scenarios to make them suitable to BDD. Scott Bellware is a man well skilled in BDD (or Context-Spesification as he like to coin it) and his article Behavior-Driven Development in Code Magazine helped me a lot on understanding the BDD way of thinking and formulating user stories.
I would also recomend the TekPub screencast Behavior-driven Design with Specflow by Rob Conery. A great intro to BDD and to a tool (SpecFlow) very good suited for doing BDD in C#.
As for TDD resources, there's already a lot of good recommendations here. But I just want to point out a couple of books that I can really recommend;
Working Effectively with Legacy Code by Michael Feathers; A must-have read if you're working on legacy code (aren't we all?) and want to get it under test
Test Driven Development: By Example by Kent Beck; If you're learning TDD why not get it from the source itself? A good book - easy to read, good humour and great thoughts.
For start do unit testing, then read about how to do it right last teach your team how to TDD and get them on board - because in my experience nothing is more important then doing unit testing with your whole team.
You'll also need a proper build process - using a build server that would build your code and run your testst I recommend using TeamCity (free with limitations).
Learning how to right good unit tests is the hard part - some of it you'll learn by yourself (as long as you keep unit testing) and the rest you can learn from searching the internet.
You'll know you've reached your goal when NOT writing unit tests as part of development will look to you just wrong.
Remember, agile means that you're not completely sold out on any particular method. If you're working on something where the benefits of TDD aren't worth it (like doing trial-and-error edits on a Swing interface), then don't use TDD.
I can't see that anybody has really expressed that TDD is not about testing. TDD-ing is about expressing the expected behaviour before doing the tiny behavioural-changing modification. This greatly improves design and enables focusing in a way I have never experienced before. You get tests that protects your future refactorings and 90% coverage for free.
To learn it I would suggest (summarising what others have said and adding one of my own):
visit the blogs and read the books mentioned above
pair up with someone proficient in TDD
practice
I practiced the Bowling kata (exercise) on my own about 20 times (about 30 minutes apiece) before I started to see the light. Started out by analysing Uncle Bob's description of it here. There are a host of katas on the codingdojo.org site including solutions and discussions. Try them!
Second piece of advice - never rely on someone else's interface. Always write, on the level of each class, to the interface you wished existed - write up an adapter to the actual implementation as necessary.
Also, I find it useful to avoid return values on methods, and to think of the code in terms of message-passing rather than function calls.
using MavenThought.Commons.Testing;
using SharpTestsEx;
namespace Price.Displacement.Module.Designer.Tests.Model.Observers
{
/// <summary>
/// Specification when diffuser observer is created
/// </summary>
[ConstructorSpecification]
public class When_diffuser_observer_is_created
: DiffuserObserverSpecification
{
/// <summary>
/// Checks the diffuser injection
/// </summary>
[It]
public void Should_return_the_injected_diffuser()
{
Sut.Diffuser.Should().Be.SameInstanceAs(this.ConcreteDiffuser);
}
}
}
这可能是 SUT 最简单的行为，因为在这种情况下，当创建它时，Diffuser 属性应该与注入的扩散器相同。我必须使用具体扩散器而不是模拟，因为在这种情况下扩散器是核心/域对象并且没有接口的属性通知。 95% 的情况下，我们会引用所有依赖项（例如 Dep()），而不是注入真实的东西。
A year ago, I had little idea how to do TDD (but really wanted to (how frustrating)) and had never heard of BDD... now I do both compulsively. I have been in a .Net development environment, not Java, but I even replaced the "F5 - Run" button with a macro to either run Cucumber (BDD) or MBUnit (TDD) depending if it is a Feature/Scenario or Specification. No debugger if at all possible. $1 in the jar if you use the debugger (JOKING (sort of)).
The process is very awesome. The framework we are additionally using is by The Oracle I've been blessed to come across, and absorbing information from, and that framework he/we use is MavenThought.
Everything starts with BDD. Our BDD is straight up cucumber ontop of iron ruby.
Feature:
Scenario: ....
Given I do blah...
When I do something else...
Then wonderful things happen...
Scenario: ...
And that's not unit testing itself, but it drives the feature, scenario by scenario, and in turn the unit (test) specifications.. So you start on a scenario, and with each step you need to complete in the scenario it drives your TDD.
And the TDD we have been using is kind of BDD in a way, because we look at the behaviours the SUT (System Under Test) requires and one behaviour is specified per specification (class "test" file).
Example:
Here is the Specification for one behaviour: When the System Under Test is created.
There is one more specification (C# When_blah_happens class file) for another behaviour when a property changes, but that is separated out into a separate file.
using MavenThought.Commons.Testing;
using SharpTestsEx;
namespace Price.Displacement.Module.Designer.Tests.Model.Observers
{
/// <summary>
/// Specification when diffuser observer is created
/// </summary>
[ConstructorSpecification]
public class When_diffuser_observer_is_created
: DiffuserObserverSpecification
{
/// <summary>
/// Checks the diffuser injection
/// </summary>
[It]
public void Should_return_the_injected_diffuser()
{
Sut.Diffuser.Should().Be.SameInstanceAs(this.ConcreteDiffuser);
}
}
}
This is probably the simplest behaviour for a SUT, because in this case when it is created, the Diffuser property should be the same as the injected diffuser. I had to use a Concrete Diffuser instead of a Mock because in this case the Diffuser is a Core/Domain object and has no property notification for the interface. 95% of the time we refer to all our dependencies like Dep(), instead of injecting the real thing.
Often we have more than one [It] Should_do_xyz(), and sometimes a fair bit of setup like perhaps upto 10 lines of stubbing. This is just a very simple example with no GivenThat() or AndGivenThatAfterCreated() in that specification.
For setup of each specification we generally only ever need to override a couple methods of the specification:
GivenThat() ==> this happens before the SUT is created.
CreatSut() ==> We auto mock creation of the sut with StructureMap and 90% of time never need to override this, but if you are constructor injecting a Concrete, you have to override this.
AndGivenThatAfterCreated() => this happens after the SUT is created.
WhenIRun() => unless it is a [ConstructorSpecification] we use this to run ONE line of code that is the behaviour we are specifiying for the SUT
Also, if there is common behaviour of two or more specifications of the same SUT, we move that into the base specifcation.
All I gotta do to run the Specification is highlight it's name, example "When_diffuser_observer_is_created" and press F5, because remember, for me F5 runs a Rake task either test:feature[tag] if Cucumber, or test:class[SUT]. Makes sense to me because everytime you run the debugger it's a throw away, no code is created (oh and it costs a $1 (joking)).
This is a very, very clean way of specifying behaviour with TDD and having really, really simple SUTs and simple specifications. If you try and be cowboy coder and write the SUT crappy with hard dependencies, etc, you will feel the pain of trying to do TDD and get fed up / give up OR bite the bullet and do it right.
And here's the actual SUT. We got a little fancy and use PostSharp to add property notify changed on the Diffuser, so hence the Post.Cast<>. And again, that's why I injected a Concrete rather than Mock. Anyway, as you can see the missing behaviour defined in another specification is when anything changes on the Diffuser.
using System.ComponentModel;
using MavenThought.Commons.Events;
using PostSharp;
using Price.Displacement.Core.Products;
using Price.Displacement.Domain;
namespace Price.Displacement.Desktop.Module.Designer.Model.Observers
{
/// <summary>
/// Implementation of current observer for the selected product
/// </summary>
public class DiffuserObserver : AbstractNotifyPropertyChanged, IDiffuserObserver
{
/// <summary>
/// gets the diffuser
/// </summary>
public IDiffuser Diffuser { get; private set; }
/// <summary>
/// Initialize with a diffuser
/// </summary>
/// <param name="diffuser">The diffuser to observe</param>
public void Initialize(IDiffuser diffuser)
{
this.Diffuser = diffuser;
this.NotifyInterface().PropertyChanged += (x, e) => this.OnPropertyChanged(e.PropertyName);
}
/// <summary>
/// Gets the notify interface to use
/// </summary>
/// <returns>The instance of notify property changed interface</returns>
protected INotifyPropertyChanged NotifyInterface()
{
return Post.Cast<Diffuser, INotifyPropertyChanged>((Diffuser)Diffuser);
}
}
}
In conclusion, this BDD / TDD style of development rocks. It took one year but I am a total convert as a way of life. I would not have learned this on my own. I picked up everything from The Oracle http://orthocoders.com/.
发布评论
评论（12）
一个好的起点是阅读博客。然后购买写博客的人的书。我强烈推荐一些：
“Uncle Bob”Martin 和 Object Mentor 的工作人员：
http://blog.objectmentor.com/
PS 获取 Bob 的《Clean Code》一书：
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
我的朋友蒂姆·奥廷格（前对象导师家伙）
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/
Jetbrains 人员：
http://www.jbrains.ca/permalink/285
我觉得有必要对此进行扩展，因为其他人似乎只是想给你提供他们对 TDD 的看法，而不是帮助你成为一名绝地忍者。 TDD 中的迈克尔·乔丹是肯特·贝克。他确实写过这本书：
http://www.amazon.com/Test- Driven-Development-Kent-Beck/dp/0321146530
他还发表博客：
http: //www.triversinstitute.org/blog/?p=29
TDD 的其他“著名”支持者包括：
他们都是值得追随的伟大人物。您还应该考虑参加一些会议，例如 Agile 2010 或 Software Craftsmanship（今年它们在芝加哥同时举行）
A good place to start is reading blogs. Then buy the books of the people who are blogging. Some I would highly recommend:
"Uncle Bob" Martin and the guys at Object Mentor:
http://blog.objectmentor.com/
P.S. get Bobs book Clean Code:
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
My friend Tim Ottinger (former Object Mentor dude)
http://agileinaflash.blogspot.com/
http://agileotter.blogspot.com/
The Jetbrains guys:
http://www.jbrains.ca/permalink/285
I felt the need to expand on this, as everyone else seems to just want to give you their opinion of TDD and not help you on your quest to become a Jedi-Ninja. The Michael Jordan of TDD is Kent Beck. He really did write the book on it:
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
he also blogs at:
http://www.threeriversinstitute.org/blog/?p=29
other "famous" supporters of TDD include:
All are great people to follow. You should also consider attending some conferences like Agile 2010, or Software Craftsmanship (this year they were held at the same time in Chicago)
我不喜欢人们说“实践 X 从来都不是坏事；如果它不起作用，那是你做得不对。”抱歉，它与任何其他过于热心的宗教教条有同样的感觉。我不买。
我同意那些人的说法，即您的时间和金钱可以负担得起的最佳解决方案应该是目标。
任何反对 TDD 的人都不应该被自动指责为忽视质量。 （“那么你什么时候停止殴打你的妻子了？”）事实上，软件中存在缺陷，必须权衡消除所有缺陷的成本与收益。
制造业也是如此。尺寸公差和表面光洁度并不完全相同，因为有时不能保证紧密公差和镜面光洁度。
是的，我会编写单元测试，尽管在编写课程之前并不经常编写。我已经看到了测试对设计的影响。我测量并观察代码覆盖率。如果我发现我的覆盖范围不可接受，我会编写更多测试。我了解重构单元测试安全网的好处。即使我独自工作时，我也会遵循这些做法，因为我亲身体验了这些做法的好处。我得到它。
但我会对任何开始就“饮食、睡眠和呼吸单元测试和 TDD”问题骚扰我的队友表示怀疑。
有没有想过这会让你听起来像个马屁精？你是否发现你的唠叨已经疏远了团队的其他成员？
这个回复可能会让我损失一些声誉，但不得不说。
我认为更好的方法是自己实践并让其他人看到好处。以身作则。这比嘴上说的更有说服力。
天哪，Grails 内置了测试生成。如果您在一个使用 Grails 的团队中工作，还需要多少销售？
I don't like it when people say "Practice X is never bad; if it doesn't work, you're not doing it right." Sorry, it has the same feel as any other over-zealous religious dogma. I don't buy it.
I agree with those folks who say that the best solution your time and money can afford should be the goal.
Anyone who objects to TDD should not automatically be accused of disregarding quality. ("So when did you stop beating your wife?") The fact is that software has bugs in it, and the cost of eliminating all of them has to be weighed against the benefit.
The same holds true in manufacturing. Tolerances on dimensions and finishes on surfaces are not all the same, because sometimes a close tolerance and a mirror finish aren't warranted.
Yes, I write unit tests, although not often before I write the class. I've seen the effect of tests on design. I measure and watch code coverage. If I find that my coverage isn't acceptable, I write more tests. I understand the benefit of a safety net of unit tests for refactoring. I follow those practices even when I'm working alone, because I've experienced the benefits first-hand. I get it.
But I'd look askance at any teammate that started bugging me about "eating, sleeping, and breathing unit testing and TDD."
Ever think that maybe this makes you sound like a suck-up? Have you found that your nagging has alienated the rest of your team?
This response might lose me a few reputation points, but it had to be said.
I think a better approach would be to practice it yourself and let others see the benefit. Lead by example. It'll be far more persuasive than running your mouth.
Geez, Grails has test generation built-in. If you're working on a team that uses Grails, how much more selling is needed?
最佳实践恕我直言：做实用的事情，而不仅仅是因为它是一个过程。不要忘记编写应用程序的目标是什么，在商业世界中，它不是编写测试。不要误会我的意思，他们有自己的位置，但这不应该是目标。
Best practice IMHO: Do what is practical and not just because it is a process. Don't forget what the goal of writing applications is, and in the business world, it isn't writing tests. Don't get me wrong, they have their place, but that shouldn't be the goal.
找一个一直在做 TDD/BDD 的人并与他们结对编程。
Find someone that has been doing TDD/BDD and pair program with them.
恕我直言，指标是从这里到那里的最佳方式。跟踪代码的覆盖情况，保留每次提交的代码复杂性增量，使用测试运行程序来监视代码的更改并不断重新运行相应的测试。切勿让测试长度超过几行，以便所有工具都能正常工作。我建议每月一次，休息一天通过突变测试器运行您的代码。那天应该只专注于编写测试。如果您还没有做好 TDD，那么所有这些都会给您带来痛苦。从痛苦中吸取教训，很快你就会做对的。
并且永远不要忽视测试的目的：描述期望的行为。它们是您的可执行规范。 （这也是我喜欢 Cucumber 的原因；现在你可以让你的 PHB 为你编写测试！好吧，也许不是非常好，但已经很接近了！）
Metrics are, IMHO, the best way to get from here to there. Keep track of how well your code is covered, keep deltas of code complexity for every commit, use test-runners that watch your code for changes and constantly re-run the corresponding tests. Never let test lengths get above a few lines, so that all your tools work well. And I'd recommend once a month, take a day off to run your code through a mutation tester. That day should be dedicated to writing tests only. All of this stuff will bring you pain if you're not already doing good TDD. Learn from the pain, and in no time at all, you'll be doing it right.
And never lose sight of what the tests are for: To describe desired behavior. They are your executable specification. (This is also why I like Cucumber; now you can get your PHB to write your tests for you! Well, maybe not quite that good, but it's close!)
“PS：我的经理说，让我升职的唯一方法是我能让团队达到 TDD/BDD。”
让团队做某事（在这个过程中不会杀死你）的唯一现实方法是向他们清楚地证明改变习惯将有利于他们。换句话说，就是写代码。很多代码。大量的代码。然后，当收到从根本上改变规范的关键电子邮件时，向他们展示您可以通过重构轻松更改代码，更糟糕的是，因为您已经做好了测试的准备。酒吧是绿色的，黑客黑客黑客，红色酒吧!!!!，黑客黑客黑客，绿色酒吧，回家。
阅读 Kent Beck 的有关测试驱动设计的书。从测试开始，然后编写代码。获取运行测试的构建服务器！您不需要为整个团队提供它 - 为自己做，并向他们展示这有帮助。
说教只会惹恼当地人:)
"PS: My manager says that the only way that will get me a promotion is if I can get the team to TDD/BDD."
The only realistic way to get a team to do something (without killing you in the process) is to demonstrate to them clearly that it will benefit them to change their habits. In other words, write code. Lots of code. Tons of code. And then when the crucial email arrive that alters the specification radically, show them that you can change your code easily with refactoring and whats worse because you were prepared for it with your tests in place. The bar was green, hack hack hack, RED BAR!!!!, hack hack hack, green bar, go home.
Read Kent Becks book about test driven design. Start with tests and then do the code. Get a build server running which RUNS THE TESTS! You do not need ot have it for the whole team - do it for yourself and SHOW them that it helps.
Preaching only annoys natives :)
我从事 TDD 已经有几年了，但最近我开始更多地研究 BDD 方式来驱动我的设计和开发。帮助我开始使用 BDD 的资源首先是 Dan North 的博客（BDD 的“创始人”）。查看BDD 简介。 behaviour-driven.org 上还有一个“官方”BDD Wiki，其中有一些值得一读的好帖子。
当我开始使用 BDD 时，我发现真正困难的一件事（并且仍然觉得有点困难）是如何制定这些场景以使其适合 BDD。 Scott Bellware 是一位精通 BDD（或者他喜欢创造的 Context-Spesification）的人，他的文章 行为驱动开发对我理解 BDD 思维方式和制定用户故事有很大帮助。
我还推荐 Rob Conery 的 TekPub 截屏视频 使用 Specflow 进行行为驱动设计。对 BDD 和非常适合在 C# 中执行 BDD 的工具 (SpecFlow) 的精彩介绍。
至于TDD资源，这里已经有很多很好的推荐了。但我只想指出几本我真正可以推荐的书；
I've been doing TDD for a couple of years, but lately I've started looking more in to the BDD way of driving my design and development. Resources that helped me get started on BDD was first and formost Dan North's blog (the 'founder' of BDD). Take a look at Introducing BDD. There's also an 'official' BDD Wiki over at behaviour-driven.org with some good post well worth reading.
The one thing that I found really hard when starting out with BDD (and still find a bit hard) is how to formulate those scenarios to make them suitable to BDD. Scott Bellware is a man well skilled in BDD (or Context-Spesification as he like to coin it) and his article Behavior-Driven Development in Code Magazine helped me a lot on understanding the BDD way of thinking and formulating user stories.
I would also recomend the TekPub screencast Behavior-driven Design with Specflow by Rob Conery. A great intro to BDD and to a tool (SpecFlow) very good suited for doing BDD in C#.
As for TDD resources, there's already a lot of good recommendations here. But I just want to point out a couple of books that I can really recommend;
首先进行单元测试，然后阅读如何正确进行测试，最后教您的团队如何进行 TDD 并让他们参与进来 - 因为根据我的经验，没有什么比与整个团队一起进行单元测试更重要的了。
您还需要一个适当的构建过程 - 使用构建服务器来构建您的代码并运行您的测试，我建议使用 TeamCity（免费但有限制）。
学习如何正确进行良好的单元测试是困难的部分 - 其中一些您将自己学习（只要您保持单元测试），其余的您可以通过搜索互联网来学习。
当您不将单元测试作为开发的一部分编写时，您就会知道您已经达到了目标，这对您来说是错误的。
For start do unit testing, then read about how to do it right last teach your team how to TDD and get them on board - because in my experience nothing is more important then doing unit testing with your whole team.
You'll also need a proper build process - using a build server that would build your code and run your testst I recommend using TeamCity (free with limitations).
Learning how to right good unit tests is the hard part - some of it you'll learn by yourself (as long as you keep unit testing) and the rest you can learn from searching the internet.
You'll know you've reached your goal when NOT writing unit tests as part of development will look to you just wrong.
请记住，敏捷意味着您不会完全放弃任何特定方法。如果您正在做的事情不值得 TDD 的好处（例如在 Swing 界面上进行试错编辑），那么就不要使用 TDD。
Remember, agile means that you're not completely sold out on any particular method. If you're working on something where the benefits of TDD aren't worth it (like doing trial-and-error edits on a Swing interface), then don't use TDD.
我看不出有人真正表示 TDD 与测试无关。 TDD-ing 是在进行微小的行为改变修改之前表达预期的行为。这极大地改进了设计，并能够以我以前从未经历过的方式集中注意力。您可以免费获得可保护您未来重构的测试和 90% 的覆盖率。
为了学习它，我建议（总结别人所说的并添加我自己的）：
的人结对我自己练习保龄球型（练习）大约 20在我开始看到光之前，（每次大约 30 分钟）。首先分析此处鲍勃叔叔的描述。 codingdojo.org 网站上有大量 katas，包括解决方案和讨论。尝试一下！
I can't see that anybody has really expressed that TDD is not about testing. TDD-ing is about expressing the expected behaviour before doing the tiny behavioural-changing modification. This greatly improves design and enables focusing in a way I have never experienced before. You get tests that protects your future refactorings and 90% coverage for free.
To learn it I would suggest (summarising what others have said and adding one of my own):
I practiced the Bowling kata (exercise) on my own about 20 times (about 30 minutes apiece) before I started to see the light. Started out by analysing Uncle Bob's description of it here. There are a host of katas on the codingdojo.org site including solutions and discussions. Try them!
引用耐克的话：JUST DO IT。
第二条建议——永远不要依赖别人的界面。始终在每个类的级别上编写您希望存在的接口 - 根据需要编写实际实现的适配器。
另外，我发现避免方法返回值，并根据消息传递而不是函数调用来考虑代码很有用。
YMMV。
To take a quote from Nike: JUST DO IT.
Second piece of advice - never rely on someone else's interface. Always write, on the level of each class, to the interface you wished existed - write up an adapter to the actual implementation as necessary.
Also, I find it useful to avoid return values on methods, and to think of the code in terms of message-passing rather than function calls.
YMMV.
一年前，我几乎不知道如何做 TDD（但真的很想（多么令人沮丧））并且从未听说过 BDD……现在我强迫性地做这两件事。我一直在 .Net 开发环境中，而不是 Java 中，但我什至用宏替换了“F5 - 运行”按钮，以运行 Cucumber (BDD) 或 MBUnit (TDD)，具体取决于它是功能/场景还是规范。如果可能的话，没有调试器。如果您使用调试器（开玩笑（有点）），则 jar 中包含 $1。
过程非常精彩。我们另外使用的框架是由我有幸遇到并从中吸收信息的 The Oracle 提供的，他/我们使用的框架是 MavenThought。
一切都从 BDD 开始。我们的 BDD 是铁红宝石上的直接黄瓜。
特点：
场景： ....
鉴于我确实废话...
当我做其他事情的时候...
然后奇妙的事情发生了......
场景：......
这不是单元测试本身，而是它逐个场景地驱动功能，进而驱动单元（测试）规范......所以你从一个场景开始，并且每个场景在驱动 TDD 的场景中您需要完成的步骤。
我们一直使用的 TDD 在某种程度上是 BDD，因为我们查看 SUT（被测系统）所需的行为，并且每个规范（类“测试”文件）指定一个行为。
示例：
以下是一种行为的规范：创建被测系统时。
对于属性更改时的另一种行为，还有一个规范（C# When_blah_happens 类文件），但它被分离到一个单独的文件中。
这可能是 SUT 最简单的行为，因为在这种情况下，当创建它时，Diffuser 属性应该与注入的扩散器相同。我必须使用具体扩散器而不是模拟，因为在这种情况下扩散器是核心/域对象并且没有接口的属性通知。 95% 的情况下，我们会引用所有依赖项（例如 Dep()），而不是注入真实的东西。
通常我们有多个 [It] Should_do_xyz()，有时还需要进行一些设置，例如最多 10 行存根。这只是一个非常简单的示例，该规范中没有 GivenThat() 或 AndGivenThatAfterCreated()。
对于每个规范的设置，我们通常只需要重写规范的几个方法：
GivenThat() ==>这发生在创建 SUT 之前。
CreateSut() ==>我们使用 StructureMap 自动模拟创建 sut，并且 90% 的时间不需要重写它，但如果您是注入 Concrete 的构造函数，则必须重写它。
AndGivenThatAfterCreated() =>;这是在创建 SUT 之后发生的。
当IRun() =>除非它是 [ConstructorSpecification]，否则我们使用它来运行一行代码，这就是我们为 SUT 指定的行为。
此外，如果同一 SUT 的两个或多个规范存在共同行为，我们会将其移至基本规范中。
要运行规范，我要做的就是突出显示它的名称，例如“When_diffuser_observer_is_created”，然后按 F5，因为记住，对我来说，F5 会运行 Rake 任务 test:feature[tag] if Cucumber，或 test:class[SUT]。对我来说这是有道理的，因为每次运行调试器时它都是一次性的，不会创建任何代码（哦，它花费 1 美元（开玩笑））。
这是一种非常非常简洁的 TDD 行为指定方式，并且具有非常非常简单的 SUT 和简单的规范。如果你尝试成为牛仔编码员并编写具有硬依赖项的蹩脚 SUT，等等，你会感受到尝试 TDD 的痛苦，然后厌倦/放弃或咬紧牙关并把它做好。
这是实际的 SUT。我们有点奇特，并使用 PostSharp 在 Diffuser 上添加更改的属性通知，因此有了 Post.Cast<>。再说一次，这就是我注入混凝土而不是模拟的原因。无论如何，正如您所看到的，另一个规范中定义的缺失行为是当扩散器上发生任何变化时。
总之，这种 BDD / TDD 开发风格非常出色。虽然花了一年的时间，但我已经彻底转变了这种生活方式。我自己是不会学到这一点的。我从 Oracle http://orthocoders.com/ 获取了所有内容。
红色或蓝色药丸，选择权在于您。
A year ago, I had little idea how to do TDD (but really wanted to (how frustrating)) and had never heard of BDD... now I do both compulsively. I have been in a .Net development environment, not Java, but I even replaced the "F5 - Run" button with a macro to either run Cucumber (BDD) or MBUnit (TDD) depending if it is a Feature/Scenario or Specification. No debugger if at all possible. $1 in the jar if you use the debugger (JOKING (sort of)).
The process is very awesome. The framework we are additionally using is by The Oracle I've been blessed to come across, and absorbing information from, and that framework he/we use is MavenThought.
Everything starts with BDD. Our BDD is straight up cucumber ontop of iron ruby.
Feature:
Scenario: ....
Given I do blah...
When I do something else...
Then wonderful things happen...
Scenario: ...
And that's not unit testing itself, but it drives the feature, scenario by scenario, and in turn the unit (test) specifications.. So you start on a scenario, and with each step you need to complete in the scenario it drives your TDD.
And the TDD we have been using is kind of BDD in a way, because we look at the behaviours the SUT (System Under Test) requires and one behaviour is specified per specification (class "test" file).
Example:
Here is the Specification for one behaviour: When the System Under Test is created.
There is one more specification (C# When_blah_happens class file) for another behaviour when a property changes, but that is separated out into a separate file.
This is probably the simplest behaviour for a SUT, because in this case when it is created, the Diffuser property should be the same as the injected diffuser. I had to use a Concrete Diffuser instead of a Mock because in this case the Diffuser is a Core/Domain object and has no property notification for the interface. 95% of the time we refer to all our dependencies like Dep(), instead of injecting the real thing.
Often we have more than one [It] Should_do_xyz(), and sometimes a fair bit of setup like perhaps upto 10 lines of stubbing. This is just a very simple example with no GivenThat() or AndGivenThatAfterCreated() in that specification.
For setup of each specification we generally only ever need to override a couple methods of the specification:
GivenThat() ==> this happens before the SUT is created.
CreatSut() ==> We auto mock creation of the sut with StructureMap and 90% of time never need to override this, but if you are constructor injecting a Concrete, you have to override this.
AndGivenThatAfterCreated() => this happens after the SUT is created.
WhenIRun() => unless it is a [ConstructorSpecification] we use this to run ONE line of code that is the behaviour we are specifiying for the SUT
Also, if there is common behaviour of two or more specifications of the same SUT, we move that into the base specifcation.
All I gotta do to run the Specification is highlight it's name, example "When_diffuser_observer_is_created" and press F5, because remember, for me F5 runs a Rake task either test:feature[tag] if Cucumber, or test:class[SUT]. Makes sense to me because everytime you run the debugger it's a throw away, no code is created (oh and it costs a $1 (joking)).
This is a very, very clean way of specifying behaviour with TDD and having really, really simple SUTs and simple specifications. If you try and be cowboy coder and write the SUT crappy with hard dependencies, etc, you will feel the pain of trying to do TDD and get fed up / give up OR bite the bullet and do it right.
And here's the actual SUT. We got a little fancy and use PostSharp to add property notify changed on the Diffuser, so hence the Post.Cast<>. And again, that's why I injected a Concrete rather than Mock. Anyway, as you can see the missing behaviour defined in another specification is when anything changes on the Diffuser.
In conclusion, this BDD / TDD style of development rocks. It took one year but I am a total convert as a way of life. I would not have learned this on my own. I picked up everything from The Oracle http://orthocoders.com/.
Red or Blue pill, the choice is yours.