Saturday, May 31, 2008

Introducing Developer Testing Into an Existing Team - Developer Thoughts

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

 dalesmithtx: :)

Share this post :

1 comment:

Kerry said...

This would be a good one to follow up with again in another 6 months, after the culture has had time to change.