4 Rules and TDD

[Burk Hufnagel]

Corey,
In the excerpt, there are several examples of test people write while working on getting their programs to work. Based on what you've seen, do most of the participants follow some form of TDD? Have you seen a difference between less experienced developers and more experienced developers regarding TDD usage?

Thanks,
Burk

[Burk Hufnagel]

Corey,
I'm also wondering if you've noticed any correlation between the use of TDD and the quality of the code people produce, or whether they manage to get the game working at the end of the allotted time.

Thanks,
Burk

[Liutauras Vilda]

Burk Hufnagel wrote:Corey,
I'm also wondering if you've noticed any correlation between the use of TDD and the quality of the code people produce, or whether they manage to get the game working at the end of the allotted time.

Burk, have a cow for quality question. Let's wait and see what author has to say about that.

[Campbell Ritchie]

Burk Hufnagel wrote:. . . the quality of the code people produce, or whether they manage to get the game working at the end of the allotted time.

Thanks,
Burk

Or whether they believe that getting the app working implies they have written good code

[Burk Hufnagel]

Campbell Ritchie wrote:Or whether they believe that getting the app working implies they have written good code

I've seen that a lot with experienced developers, but when I ask them how often they refactor their code, the smiles go away...

[Burk Hufnagel]

Liutauras Vilda wrote:Burk, have a cow for quality question. Let's wait and see what author has to say about that.

It's been a while since I last visited. I had to look up the significance of receiving a cow. Thank you. I appreciate it.

[Liutauras Vilda]

Burk Hufnagel wrote:when I ask them how often they refactor their code

I guess quite usual answer is when current implementation no longer works with new requirements. So really there is no quality evolution with an existing functionality. Which is of course sad.

[corey haines]

Burk Hufnagel wrote:Corey,
In the excerpt, there are several examples of test people write while working on getting their programs to work. Based on what you've seen, do most of the participants follow some form of TDD? Have you seen a difference between less experienced developers and more experienced developers regarding TDD usage?

Thanks,
Burk

Hi!

I think a lot of that depends on the constraints and people's familiarity with TDD. Most people that I ran into came to a coderetreat with the expectation that it was "a chance to practice or learn TDD," so they at least tried. Personally I always emphasized that a coderetreat is a great time to try new things, since the goal isn't to finish the implementation, nor even to get anywhere at all. If a single test is written, but it is a great test, then that session should be considered successful.

-Corey

[Burk Hufnagel]

Liutauras Vilda wrote:I guess quite usual answer is when current implementation no longer works with new requirements. So really there is no quality evolution with an existing functionality. Which is of course sad.

But if the code no longer meets the requirements that means the new version behaves differently than the original code, so the change doesn't qualify as a refactoring. Right?

[Burk Hufnagel]

corey haines wrote:Hi!

I think a lot of that depends on the constraints and people's familiarity with TDD. Most people that I ran into came to a coderetreat with the expectation that it was "a chance to practice or learn TDD," so they at least tried. Personally I always emphasized that a coderetreat is a great time to try new things, since the goal isn't to finish the implementation, nor even to get anywhere at all. If a single test is written, but it is a great test, then that session should be considered successful.

-Corey

Thank you for the response. I was hoping to leverage your experience and get a feel for TDD adoption around the globe. Based on what I've seen in Atlanta, GA, USA, it seems that TDD still isn't common (less than 50% use it) and that many senior developers don't want to try it because... fill in the blank -- while younger developers at least seem open to the idea, give it a shot and mostly find it valuable.

[Junilu Lacar]

There are many reasons for people not adopting TDD into their development practice. One of the biggest reasons, I think, is the lack of understanding what TDD actually is. Many people think it's just Red-Green-Refactor. To me, that's just the tip of the iceberg. That's like saying driving a car is as simple as turning the ignition, putting the car in gear, pressing down on the gas pedal, steering, and when appropriate, stepping on the brakes. Sure, both are as simple as that if you boil it down to bare essentials. But anyone who has driven a car or has done TDD properly knows that's not exactly all there is to it. There's a lot more. A whole lot more.

I find it amazing how a simple problem like The Game of Life can be the source of so much learning about design. I find it amazing that four simple rules can have so much impact on design. To me, Corey's book is like the Red Horse Beer* (the original formulation) of design books.

*Red Horse Beer is an extra strong beer brewed by San Miguel Corp. (Philippines). To get a sense of what "extra strong" beer is, RHB:Budweiser as Condensed milk:water.

[Junilu Lacar]

Adopting TDD involves many mindset shifts. One such shift for me was accepting the proposition that coding is design. See Jack Reeves' essays on this topic.

Another mindset shift is that tests are detailed design specifications. Tests are experiments about design options. You run these experiments to see if a particular design choice makes sense. If not, you throw it away and come up with a different design choice and a test to experiment with it.

You also have to look at tests as something that you use to reveal problems in your code, not so much to show that your code works. When you use tests this way, TDD starts to make a lot more sense. As E.W.Dijkstra said: "Program testing can be used to show the presence of bugs, but never to show their absence!"

[corey haines]

Burk Hufnagel wrote:Corey,
I'm also wondering if you've noticed any correlation between the use of TDD and the quality of the code people produce, or whether they manage to get the game working at the end of the allotted time.

Thanks,
Burk

In the context of coderetreat sessions, I don't think I've really seen that much of a correlation. A lot of the time, when I was facilitating, I would emphasize putting a lot of thought into the quality of the tests and how they can influence the design, rather than explicitly working on writing a lot of code, especially enough to see an impact.

one thing I notice a lot is that people often tend to be more on the "test-first" side of coding, rather than the "test-driven" side, meaning that they are writing tests to verify the design they want to implement, rather than writing a test to outline or specify some behaviour and then really truly write just enough code to get it passing, followed by a heavy refactoring stage.

This is often shown by a jump towards the "how I am going to implement a grid" discussion. Rather than talking about the qualities of the grid under evolution.

[corey haines]

Burk Hufnagel wrote:

Liutauras Vilda wrote:I guess quite usual answer is when current implementation no longer works with new requirements. So really there is no quality evolution with an existing functionality. Which is of course sad.

But if the code no longer meets the requirements that means the new version behaves differently than the original code, so the change doesn't qualify as a refactoring. Right?

This goes back to the old quote (i think it was either Kent Beck or Ward Cunningham) about "if you have a hard change coming up, refactor the code until the hard change becomes easy (note: this may be hard), then make the easy change."

For me there are (at least) two levels of refactoring:
- General cleanup of code directly after having written it. This involves abiding closely by the 4 rules of simple design, especially naming and duplication. After writing some code, look to see if you have any small, easy changes to make to clean things up.
- Pre-feature adjustement. This is what the quote kind of refers to. When you have a new feature, one that you either didn't anticipate or just didn't worry about at the time the code was written, it can be helpful to now look at your design and see if it is welcoming to the new feature. If it isn't, perhaps there are some changes that can be made that will make it more accepting. If so, then make those. Don't change the behaviour, just alter the design to make the new feature more easy to implement. Then implement it.

[corey haines]

Burk Hufnagel wrote:

corey haines wrote:Hi!

I think a lot of that depends on the constraints and people's familiarity with TDD. Most people that I ran into came to a coderetreat with the expectation that it was "a chance to practice or learn TDD," so they at least tried. Personally I always emphasized that a coderetreat is a great time to try new things, since the goal isn't to finish the implementation, nor even to get anywhere at all. If a single test is written, but it is a great test, then that session should be considered successful.

-Corey

Thank you for the response. I was hoping to leverage your experience and get a feel for TDD adoption around the globe. Based on what I've seen in Atlanta, GA, USA, it seems that TDD still isn't common (less than 50% use it) and that many senior developers don't want to try it because... fill in the blank -- while younger developers at least seem open to the idea, give it a shot and mostly find it valuable.

Honestly I don't think the adoption is that high anywhere. It can be easy to get into a bubble and start to think that it is more common than it actually is.

I do believe that automated testing has been ever-increasing, then to a slightly lesser extent having developers work on the automated tests. Writing the tests first, which is a natural step towards, TDD, can be counter-intuitive and hard to find the time to learn.

My general approach in the past with people who were resistant was to ask how they currently verified their code (focus on the test part, rather than the design part), both at the time of writing and in regression. Most developers I've met have some way they do it. Then, we can talk about some of the benefits of a test-first/test-driven methodology and see if there are differences. I've known some folks in the past who did just fine without it, and the effort of switching to use this technique wouldn't have really been that valuable to them. The easiest and biggest benefit comes from folks who don't have an existing way to do it.

[Junilu Lacar]

corey haines wrote:one thing I notice a lot is that people often tend to be more on the "test-first" side of coding, rather than the "test-driven" side, meaning that they are writing tests to verify the design they want to implement, rather than writing a test to outline or specify some behaviour and then really truly write just enough code to get it passing, followed by a heavy refactoring stage.

Interesting. I've always thought that the transition from "test-first programming" in the late 1990s to "test-driven development" was influenced by the same kind of forces that moved us from "janitor" to "property custodian". EDIT: To explain that more, a janitor is somebody who just cleans whereas a property custodian does way more than just clean. I thought the transition from "test-first programming" to "test-driven development" had similar forces behind it because there was a point where some people were calling it "test-driven design" as well.

On the other hand, I have also seen "test-first" being used as a sort of umbrella term for any technique that starts with tests first, versus tests after. That is, "BDD, ATDD, and TDD are all 'test-first' techniques."

[corey haines]

I've always thought that the transition from "test-first programming" in the late 1990s to "test-driven development" was influenced by the same kind of forces that moved us from "janitor" to "property custodian".

I think there is no real consensus on the "meaning" of the terms. Both test-first and test-driven involve writing tests first. However, I have found it useful to think of the difference revolving around what your reaction is when you find code that is hard to test.

test-first: this code is hard to test, let me see make some changes to the test to enable testing the code.

test-driven: this code is hard to test, let me make some changes to the code to enable testing the code.

Why do I make this distinction? I find it easier to introduce people to the concept when you can move through a progression of learning techniques:

- Write all your code, write all your tests
- Write some code, write tests for that code
- Write a tiny bit of code, write tests for that code
- Write code and tests simultaneously
- Write test first, then write code
- Write test first, design code based on making those tests easy to write

It also helps differentiate between "test-first"  being about verification and "test-driven" being about design. Changing your test to enable you to test the code is about verifying that the code works. Changing your code to make it easy to test is about adjusting your design because of the need for the test.

I've found making an explicit distinction like this helps in conversation, so we know what we are talking about.

As I said at the beginning, I would easily wager a lot of money that you could find someone readily who disagrees with me on these definitions and uses their own.

[Junilu Lacar]

corey haines wrote:I find it easier to introduce people to the concept when you can move through a progression of learning techniques:

- Write all your code, write all your tests
- Write some code, write tests for that code
- Write a tiny bit of code, write tests for that code
- Write code and tests simultaneously
- Write test first, then write code
- Write test first, design code based on making those tests easy to write

Thanks again, Corey. I hope you won't mind if I "borrow" this.