Archive for the ‘TDD’ Category

How do I introduce Steve? I am trying to remember when I first met Steve. That’s hard, Steve is the kind of guy who seems to be shy and in the background. Yet, when he says something, people listen. Today I noticed that I followed a session of him and Joseph Pelrine At xpdays 2005. Only I don’t remember him from the session. I like that, because that shows that Steve lets his message be more important then his person. And in the end, people will remember that. (At least that is how it works for me.) Steve was a founder and one of the driving forces behind XTC).
He wrote Growing Object-oriented Software guided by tests. A wonderful book that explains why and how to do TDD (And should be mandatory reading for developers.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

What is something people usually don’t know about you but has influenced you in who you are?

When I stumbled into software, back in the Paleozoic era (Pascal with punch cards on an ICL Atlas), one of the things that attracted me into the game was that the previous generation I met was full of interesting misfits. They’d fallen into the industry because it was interesting and at the time there was no formal career path to weed them out.

If you would not have been in IT, what would have become of you?

Maybe a statistician, it’s where I had my best grades. Either that or a failed musician.

What is your biggest challenge and why is it a good thing for you?

My impatience. I would have been able to get more done by letting things take their course.

What drives you?

Wanting to build stuff that’s actually useful to someone. It turns out to be surprisingly difficult to arrange.

What is your biggest achievement?

my family

What is the last book you have read?

Eating Animals by Jonathan Safran Foer Appalling, if true.

What question do you think I should also ask and what is the answer?

What would you most like to change in the software industry?

Too few people have ever had a really good development experience. Most literally don’t know what they’re missing, so they can’t make realistic trade-offs. I’d love to find a way to make that more widely available.

Who do you think I should ask next?

Last week I published JB‘s questions about TDD.
These are his answers.
1. What kind of technique is TDD?
(a) It is a testing technique
(b) It is a design technique
(c) It is a learning technique
(d) It is an overall feature delivery technique
(e) More than one of the above applies
Answer: e. If you doubt that d is true, then see the very beginning of http://c2.com/cgi/wiki?TestDrivenDevelopment
2. Which of these is necessary to do TDD?
(a) Write tests before production code
(d) Write failing tests, then pass them, one by one
(e) Refactoring
Answer: a, d, and e, but not b, c nor f
3. Which of the following activities does TDD replace?
(d) Debugging
Answer: only d, if you’re really good, but none of the rest
4. If we do TDD well, which of these statements is true about our code base?
(d) The cost of adding new behavior is relatively very low
(f) We feel confident in maintaining it indefinitely
Answer: very probably d and f, but the other statements are far too absolute to be true in general. We probably have very high code coverage. We probably have very little duplication and very clear code in the part of the code base that has changed the most. We probably have very few defects and defects arrive at rate that depends on the age of the code base, rather than its size.
Enjoy.
I agree with JB that you should first read the wiki article on C2. IT’s the basic of a lot in XP if not agile. (if you did not know C2 is the first public wiki)
Here are some more links
Next you can read anything that Brian Marick wrote in TDD
I don’t always agree with Scott Ambler: but this post seems like a nice one on TDD
If that is not enough, check out these books:
If you had a doubt if answer 2 E was right, check out  Agile in a Flash about TDD. JB used here refactoring the way we use it in agile. Not the way some companies call “large 3 years rework”, refactoring.

Last week I started  ATQ. Instead of me inventing all questions I asked some agile friends. This week JB Rainsberger gave me questions for TDD. (Which is cool as today we have XPDays Benelux and JB is here…)

(If you too have one or more ideas for another ATQ, please contact me)

 

1) What kind of technique is TDD?

A) It is a testing technique

B) It is a design technique

C) It is a learning technique

D) It is an overall feature delivery technique

E) More than one of the above applies

F) None of the above

 

2. Which of these is necessary to do TDD?

A) Write tests before production code

B) Decide all the tests you plan to write before writing them

C) Make all design decisions after you start writing code

D) Write failing tests, then pass them, one by one

E) Refactoring

F) Apply Design Patterns

 

3. Which of the following activities does TDD replace?

A) Design sessions, such as whiteboarding, CRC, architecture debates

B) Manual testing by skilled testers

C) Manual test plan execution

D) Debugging

E) Automated system testing

F) Documenting APIs we intend to publish

 

4. If we do TDD well, which of these statements is true about our code base?

A) We have 100% code coverage

B) We have no duplicate code

C) Our code is crystal clear

D) The cost of adding new behavior is relatively very low

E) We have no defects

F) We feel confident in maintaining it indefinitely