This link has been bookmarked by 210 people . It was first bookmarked on 06 Dec 2006, by Akbar Zamir.
-
25 Aug 15
-
11 Apr 12
-
05 Mar 12
-
14 Jan 12
-
03 Jan 12
-
21 Nov 11
-
06 Nov 11
-
31 Oct 11
-
17 Sep 11
-
24 Aug 11
-
20 Jun 11
ken .Having gone down many blind alleys, coming to grok issues with tests...
"It suddenly occurred to me that people’s misunderstandings about TDD almost always came back to the word “test”
"Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What’s more, they found that when they wrote the method name in the language of the business domain,the generated documents made sense to business users, analysts, and testers."6 * agile business communication knowledge learning software testing
-
05 Jun 11
-
01 Jun 11
-
17 May 11
-
05 May 11
-
20 Apr 11
-
10 Apr 11
-
08 Apr 11
James HolyheadWhiile using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.
-
31 Mar 11
-
28 Feb 11
-
21 Feb 11
-
14 Feb 11
-
24 Jan 11
erikars"Then I came across the convention of starting test method names with the word “should.” This sentence template – The class should do something – means you can only define a test for the current class. This keeps you focused. If you find yourself writing
-
19 Jan 11
-
03 Apr 10
-
11 Mar 10
-
25 Feb 10
-
18 Feb 10
-
17 Feb 10
-
03 Feb 10
-
27 Jan 10
-
10 Jan 10
-
08 Jan 10
-
22 Dec 09
-
25 Nov 09
-
24 Nov 09
-
03 Nov 09
-
02 Nov 09
-
14 Oct 09
-
13 Oct 09
-
23 Sep 09
-
22 Sep 09
-
17 Sep 09
-
02 Sep 09
-
31 Aug 09
-
26 Aug 09
-
14 Aug 09
-
30 Jul 09
-
09 Jul 09
-
29 Jun 09
-
09 Jun 09
-
21 May 09
-
10 May 09
-
22 Apr 09
-
21 Apr 09
-
19 Apr 09
elle mI had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and
software programming development testing methodology agile bdd tdd
-
16 Apr 09
-
11 Apr 09
-
01 Apr 09
-
29 Mar 09
-
25 Mar 09
-
19 Mar 09
Yeray DariasMy response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider pictu
software development testing programming agile xp ddd bdd tdd
-
10 Mar 09
-
My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.
-
I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development.
-
What’s the next most important thing the system doesn’t do?
-
Toward the end of 2004, while I was describing my new found, behaviour-based vocabulary to Matts, he said, “But that’s just like analysis.” There was a long pause while we processed this, and then we decided to apply all of this behaviour- driven thinking to defining requirements. If we could develop a consistent vocabulary for analysts, testers, developers, and the business, then we would be well on the way to eliminating some of the ambiguity and miscommunication that occur when technical people talk to business people.
-
where Y is some feature, Z is the benefit or value of the feature, and X is the person (or role) who will benefit. Its strength is that it forces you to identify the value of delivering a story when you first define it.
-
When there is no real business value for a story, it often comes down to something like ” . . . I want [some feature] so that [I just do, ok?].” This can make it easier to descope some of the more esoteric requirements.
-
-
04 Mar 09
-
18 Feb 09
-
17 Feb 09
-
22 Jan 09
-
12 Jan 09
-
09 Jan 09
Emmanuel HugonnetI had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and
-
08 Jan 09
-
26 Dec 08
-
27 Nov 08
-
when they wrote the method name in the language of the business domain,the generated documents made sense to business users, analysts, and testers.
-
convention of starting test method names with the word “should.” This sentence template – The class should do something – means you can only define a test for the current class. This keeps you focused. If you find yourself writing a test whose name doesn’t fit this template, it suggests the behaviour may belong elsewhere.
-
If a class is doing more than one thing, I usually take it as an indication that I should introduce other classes to do some of the work. I define the new service as an interface describing what it does, and I pass this service in through the class’s constructor
-
I found that if I was changing code and caused a test to fail, I could look at the test method name and identify the intended behaviour of the code.
-
people’s misunderstandings about TDD almost always came back to the word “test”.
-
What to call your test is easy – it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot – you can only describe so much behaviour in a single sentence. When a test fails, simply work through the process described above – either you introduced a bug, the behaviour moved, or the test is no longer relevant.
-
JBehave
-
I found that a really useful way to stay focused was to ask: What’s the next most important thing the system doesn’t do?
This question requires you to identify the value of the features you haven’t yet implemented and to prioritize them. It also helps you formulate the behaviour method name: The system doesn’t do X (where X is some meaningful behaviour), and X is important, which means it should do X; so your next behaviour method is simply:
public void shouldDoX() {
// ...
}
Now I had an answer to another TDD question, namely where to start.
-
a story template that looked like this:
As a [X]
I want [Y]
so that [Z]where Y is some feature, Z is the benefit or value of the feature, and X is the person (or role) who will benefit. Its strength is that it forces you to identify the value of delivering a story when you first define it.
-
A story’s behaviour is simply its acceptance criteria
-
We started describing the acceptance criteria in terms of scenarios, which took the following form:
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes. -
Acceptance criteria should be executable
-
-
26 Nov 08
-
18 Nov 08
-
14 Nov 08
-
08 Oct 08
-
29 Sep 08
-
22 Sep 08
-
14 Aug 08
-
04 Aug 08
-
22 Jul 08
-
07 Jul 08
-
18 Jun 08
Mark PawelekDanNorth.net » Introducing behaviour-driven development (BDD)
-
16 Jun 08
-
23 May 08
-
07 May 08
-
24 Apr 08
-
18 Apr 08
-
12 Apr 08
-
08 Apr 08
-
20 Mar 08
-
04 Mar 08
-
22 Feb 08
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.