Creed, Cult, and Code: Introducing Developer Testing Into an Existing Team

My friend Chad Myers posted recently about Introducting Quality-first Notions Into an Existing Team. Since you are such a devoted fan of my blog, you undoubtedly know that we have recently introduced Test Driven Development, or at least automated developer testing, to our team in the context both a waterfall project and an Agile project. Chad's post made me interested to see what folks on our team thought about developer testing now that they have been doing it for a bit. So I’ve been asking folks what they think of developer testing, specifically whether or not they thought it was worth it and what it was that made them think that. My point in doing this is that I want to gain actual value from our testing efforts, and not just remain in the “testing enthusiast” camp. I, of course, am sold on the idea of developer testing, but I thought you would like to see some of the responses I got:

dalesmithtx: What was the tipping point for you that helped you decide automated developer testing was a worthwhile thing?_________________________________________________________

DEV 1: Well, I'd say there was no tipping point. It was more of a feeling of: I can't wait until we get this going. Here are my feelings.

- The last shop I worked in used it and it proved its worth over and over. I was the one who setup and ran the test scripts so I saw the effort through from beginning to end first hand.

- It's another means to increase our test coverage although it's not meant to be a substitute for other types of testing.

- It helps enforce more testing by developers. For those developers who have not been exposed to test driven development, it's a big change. It's easy to just write code but it's also risky. Test driven development allows the developer a chance to think things through before writing code.

- I like to see you smile.

dalesmithtx: Aww, that's so sweet!

DEV 1: heh heh

_________________________________________________________

DEV 2: when I ran nUnit and saw all the blinky green lights?

dalesmithtx: good point

_________________________________________________________

DEV 3: hmm...

DEV 3: i guess i'd have to say finding mistakes in code while writing tests, which saves you some time up front when you start smoke testing. it showed me that you are not just investing additional time - you're saving time in other areas, so the overall investment is only slightly more, but the benefits are far reaching.

dalesmithtx: Very cool

dalesmithtx: DEV 2's answer:

DEV 2: when I ran nUnit and saw all the blinky green lights

dalesmithtx: Yours is a bit more helpful

DEV 3: haha... that's a big one too... until you see all green, you hate testing :-()

DEV 3: :-)

dalesmithtx: yup

_________________________________________________________

DEV 4: I think the real selling point for me occurs when you later make some changes you don't anticipate will be problematic and then find out some the tests failed. If not for the testing, there would have been issues.

DEV 4: You can also refactor with much greater confidence.

dalesmithtx: DEV 2's answer:

DEV 2: when I ran nUnit and saw all the blinky green lights

DEV 4: I think he meant red.

dalesmithtx: :)

__________________________________________________________

DEV 5: yea for me it was the first time I broke a test

DEV 5: went oh rainbow

DEV 5: that saved me 2 hours

DEV 5: I transposed two strings

DEV 5: was supposed to be string str3 = str1 + str2;

DEV 5: instead I did

DEV 5: string str3 = str2 + str1

DEV 5: in one function

DEV 5: unit test caught it instantly

DEV 5: would have taken me at least 2 hours to get UI setup to test

dalesmithtx: yeah

dalesmithtx: Yeah, for me it was really hooking up automated testing with CI, which we haven't really emphasized here yet

dalesmithtx: At least not on our current project

dalesmithtx: As soon as it clicked with me that a failed test means a failed build, I got it

DEV 5: yea

DEV 5: I think DEV 7 has best def yet though

DEV 5: its used like double blind accounting

DEV 5: & for the same reason

DEV 5: chances are you won't make the same mistake in the same way both places

dalesmithtx: right, I like that

DEV 5: yea so do I

____________________________________________________________

DEV 6: hmmmm

DEV 6: for one confidence in your code of what it does and does not ...

dalesmithtx: Do you remember if there was a particular incident? Or was it more of a general sense, arrived at through multiple tests?

DEV 6: ... and knowing what you delivered in regard to the business rules in the spec ...

DEV 6: yea a general sense via tests

DEV 6: no ah hah moment :)

dalesmithtx: right

____________________________________________________________

DEV 7: Your and DEV 8's respect

dalesmithtx: :)

dalesmithtx: that ain't worth much

DEV 7: I have to be honest I did not do it as much as I should have

DEV 7: And let it slide by the wayside when the project got well under way

DEV 7: :(

DEV 7: I just lost it

DEV 7: your respect that is

dalesmithtx: :)

dalesmithtx: nah

DEV 7: So, I hope to win your argument I get more issues with my code :)

DEV 7: I am still interested in approaching code that way

dalesmithtx: What are the implications of introducing developer testing to a legacy environment?

DEV 7: Just felt very rushed through much of the project

dalesmithtx: sure

dalesmithtx: that's the reason I'm asking though - just wondering what it has really gained us so far, and what we would change in future development efforts to get more out of developer testing

DEV 7: I know I dropped it around the time I had issues testing DB calls

DEV 7: But I see that as soon as those calls are at least a call away thet get mocked out anyway

dalesmithtx: so that's in interesting point - getting tangled up in physical dependencies is definitely a stumbling block to widespread adoption

dalesmithtx: understanding techniques on how to deal with those situations would help, but we have to have a vision on why we should do this in the first place

DEV 7: More practice would have let me see that it's not such a huge issue

DEV 7: Cool

dalesmithtx: sure, absolutely

dalesmithtx: I'm also interested in how to communicate the vision of what testing brings to others in our organization

DEV 7: Well hopefully you can get some good examples out of [our current project] code

dalesmithtx: and [our other current project]

DEV 7: Leave it anonymous though, so people don't think that I cause so many bugs

dalesmithtx: LOL

DEV 7: hehheeh

___________________________________________________________

DEV 8: i just generally think automated developer machines (ADM) are very cool

DEV 8: but it was when Chad [Myers] came to [my former employer] and showed us the error of our ways. I was converted by an itinerant preacher