GeeCON Prague 2014*
The moose likes Agile and Other Processes and the fly likes Teaching Test Driven Development Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Teaching Test Driven Development" Watch "Teaching Test Driven Development" New topic
Author

Teaching Test Driven Development

Tina Coleman
Ranch Hand

Joined: Dec 12, 2001
Posts: 150
I'm giving a brown-bag chat on test driven development next week, and am fleshing out my outline... The idea is to give a "real-world" view of how to do TDD, meaning that I have to convince individual developers of its value to them and potentially have them recognize the benefits of a TDD approach in a company that doesn't have any particular development process, agile or otherwise, in place.
My basic outline of the presentation thus far runs along the lines of what TDD is, what its benefits are, and then what stumbling blocks folks run into and how to overcome them. Stumbling blocks both include bad habits to overcome (and how to break those habits), as well as things considered harder to test and what kinds of tools or patterns to use to overcome those problems. What kinds of things would you consider gotta-haves in such a presentation?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
What is a "brown-bag chat"? What's your goal for doing it?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
the biggest gottahaves are compelling arguments for both developers (who are usually receptive to new ideas) AND management (who usually are less so) that TDD is "a good thing".
Especially management needs to be converted into really believing and understanding that the extra up-front investment (after all it takes a bit longer to see the first screen flashing to live in the first demo) will save them money in the long term.
So you will need to give the developers ammunition not only to convince themselves that they want it (plus the tools to do it with, or pointers of where to get those tools) but also ammunition to convince their management that it is what the management wants.


42
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
What is a "brown-bag chat"?

Brown-bag sessions are traditionally educational meetings held during the lunch hour. The "brown-bag" comes from the brown paper bags in which the staff carries their lunch with them into the meeting room. We used to have this kind of sessions in my last project and I can recommend them from all my heart.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
What kinds of things would you consider gotta-haves in such a presentation?

I'd say getting support of senior management / technical architects is a must. If you can convince them that there's value in whatever you are brown-bagging, you should be able to get the most mileage.
If it's just a study-group I'd say still start with Senior Management. They have the skills and resources to get it off the ground quicker, all things being equal. Who knows they may even be able to get Kent Beck in to lead a session or two ?
Good management will let you convince yourselves first, which I expect you do the more you try to convince them.
regards
[ October 03, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Lasse, thanks for the explanation!
I wouldn't go into too much detail in such a presentation. If someone argues with "but XXX is hard to test/cannot be reasonably tested", I'd just answer something along the lines of:
"You are right, testing XXX isn't as straightforward as testing vanilla business logic. There are some techniques to apply, though - most of them having to do with introducing more abstractions/indirections and replacing parts of the system with testing dummies. I don't think we need to handle those from the beginning, though. We should start testing the 'low hanging fruits' to get a hang of it. Once we have a feeling for unit testing, we can start to tackle the harder parts."
I would still be interested in what result of the presentation you strive for.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Colleagues of mine who have introduced a test-driven approach report great success in getting who ever currently does the after-the-fact testing on your side first. Dissenters from development, architecture or management then get hit from both sides.
Despite the fact the we know that test-driven-development is primarily a design/development activity, its easy for people to stop listening at the "test" bit, and assume it is just something for the regular test guys. Good testers, on the other hand are ususlly very quick to latch on to the idea of concrete acceptance tests developed before each piece of work.
On the other hand, if the test team just hear a load of goosip about how some developer is proposing an overhaul of the way testing is done, they are likely to feel indignant, and throw their weight against the proposal.
The bottom line. In your rush to explain to architects, developers and managers, don't forget the testers, they can be your best allies or your worst enemies.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
I'd say getting support of senior management / technical architects is a must.

I disagree. Generally, management shouldn't be interested in how I write my code. If you start to write a test today, how should management even notice?
If you can convince them that there's value in whatever you are brown-bagging, you should be able to get the most mileage.

With *that*, I agree. If you can get the whole team to commit trying TDD for two weeks, inclusive appropriate time for trial-and-error learning, workshops as needs arise or even an experienced coach, that would certainly be great!
If you can't do that, in my experience a presentation doesn't help that much. Just doing it yourself and spreading the technique by doing Pair Programming has been much more effective to me.
Tina Coleman
Ranch Hand

Joined: Dec 12, 2001
Posts: 150
Answering a few questions folks have asked:
* what's a brown-bag chat (BBC) - basically, someone volunteers to present some topic during lunch time. Folks can bring their lunch, or sometimes the company provides pizza, but it's on your own time - you're not allowed to count that as part of your regular worktime for the week. We generally try to keep a regular rotation of BBCs going, just to get some exposure to ideas and techniques, and to keep some sense of community amongst the staff.
* The aim of the talk: Essentially, though it'd be nice to win a full-scale conversion of folks, I'd be content with just getting a few more folks interested in trying it out. The way our company works, things bubble up - we're very project-centric, so if one project has success using a technique, then that technique will probably be reused across the next project those folks are on. If you try to push something from the top down, one, senior management doesn't pay that much attention, and two, inevitably there's more resistance. Often works better if things gradually coalesce where we have folks trying something, gaining experience, and swapping notes/experiences via the various technical mailing lists in-house.
* The audience of the talk: we have an internal Java technical community. Because it's done on our own time (lunch-time), typically the attendees are the more senior architects and tech leads who are interested in exploring better ways of doing things. We don't have a testing division in-house: we do have a few testers, but they're often assigned to only the very largest projects. My intent is to make an announcement to all of the technical staff (testers, Java folks, etc) about the topic, but I'm not expecting much of a response from the test team - most of 'em are out at client sites.
I'm pulling together my presentation outline and notes this weekend. I've got Kent Beck's Test Driven Development book, as well as have done more research out on testdriven.com, etc. Basically, the thought is that I need to make a convincing case that TDD makes it _easier_ to develop good code and that it gives you greater confidence that you're putting out quality stuff. I can point to some success on some of my own projects, things that I've been saved by, and things where I wish I had done it better or would now do things differently given a bit more background.
The only unfortunate thing about this whole presentation is that it looks like I won't actually be the one to deliver it, else I'd offer to report back how the presentation went. (Got a backup presenter in the wings - will hand off my outline/notes/sample code for him to tweak and present...) Looks like I'll be in a hospital delivering baby coder #2 next week on the day I would have given the presentation! I haven't found a test driven form of child rearing yet - if anyone has any leads, I'm all ears.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Originally posted by Ilja Preuss:

---------------------------------
Originally posted by HS Thomas:
I'd say getting support of senior management / technical architects is a must.
---------------------------------
I disagree. Generally, management shouldn't be interested in how I write my code. If you start to write a test today, how should management even notice?

You ARE naive
Management are the guys who think in KLOCs and gauge your productivity in that.
Testcode isn't part of the code that gets built into the delivered product therefore doesn't apply to the KLOC count, therefore you're improductive...
Happily this extreme is getting less and less, but the principle holds.
darn board doesn't support nested quotes
[ October 03, 2003: Message edited by: Jeroen Wenting ]
[ October 03, 2003: Message edited by: Jeroen Wenting ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
I haven't found a test driven form of child rearing yet - if anyone has any leads, I'm all ears.

Test for dampness at both ends
Remove *smells*
Refactor
Discipline

Iterate for as few years as the allowed by the the pointy haired government while going through Acceptance Testing
And finally , ship to Production!


Good luck with the new venture.
[ October 03, 2003: Message edited by: HS Thomas ]
Tina Coleman
Ranch Hand

Joined: Dec 12, 2001
Posts: 150
Management are the guys who think in KLOCs and gauge your productivity in that.
Testcode isn't part of the code that gets built into the delivered product therefore doesn't apply to the KLOC count, therefore you're improductive...

Happily (in this case, anyway), the definition of productivity in our company works out more to be: write code that works now, doesn't cause us to have horrible maintenance problems later, and that fits within the time allotted for development of the feature. Assuming you meet all three of those areas, then you're "productive" (never mind that you don't then have good data to make the next estimate and schedule, but that's another issue). So, that TDD lets me verify that it works now, that I can verify that it works later, and (at least by anecdotal evidence) keeps me from spinning my wheels so that I can build the feature within its time allotted, TDD fits our ad-hoc definition of productivity. (Hmmm... maybe that's the best way to spin it in the presentation, too.)
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Originally posted by Illja Preuss:
I disagree. Generally, management shouldn't be interested in how I write my code. If you start to write a test today, how should management even notice?

It's quite a difficult process to grasp initially, Illja.
I'd be surprised if Management should be kept in the dark as to how it works. If all they are interested in is results, fair enough.
If they want to repeat or improve on those achievements they'd better understand the process for future hiring.
But you are right it's a process that's difficult to understand unless you are doing it and XP teams does "adopt" it's fresh-faced developers and train them. So perhaps Management should stay away from it altogether :roll: as long as they are confident that they have a good XP team-leader. ( Some teams think they are practicising XP but they are not really , is what one hears quite often).
regards
[ October 03, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
I'd be surprised if Management should be kept in the dark as to how it works. If all they are interested in is results, fair enough.
If they want to repeat or improve on those achievements they'd better understand the process for future hiring.

Sorry, I didn't mean to actively hide from them when they are interested in how I can produce working code so fast...
I just don't think that it's managements job to *force* me how to code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tina Coleman:
(Hmmm... maybe that's the best way to spin it in the presentation, too.)

Sounds good!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeroen Wenting:
You ARE naive

No - idealistic.

Management are the guys who think in KLOCs and gauge your productivity in that.

Perhaps in your world. Perhaps it's time to change your world, or to change your world...
Testcode isn't part of the code that gets built into the delivered product therefore doesn't apply to the KLOC count, therefore you're improductive...

And how much time do you spend *debugging* your code? How productive is *that*?
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Perhaps it's time to change your world, or to change your world...

A Freudian slip ? :roll:
regards
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Change the world = move into another world
Change the world = make the world a different place
More often heard in the form of "change the organization or change the organization"...
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks, Lasse.

Happily (in this case, anyway), the definition of productivity in our company works out more to be: write code that works now, doesn't cause us to have horrible maintenance problems later, and that fits within the time allotted for development of the feature. Assuming you meet all three of those areas, then you're "productive" (never mind that you don't then have good data to make the next estimate and schedule, but that's another issue).


Hmm. Remarakably close to test-driven child rearing, then!
regards
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
Change the world = move into another world
Change the world = make the world a different place
More often heard in the form of "change the organization or change the organization"...

Yep! Typically attributed to Martin Fowler: http://c2.com/cgi/wiki?ChangeYourOrganization
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
The Change Your Organisation Diary is an interesting read. Particularly MatrixManagement and some other links.
regards
[ October 04, 2003: Message edited by: HS Thomas ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This got a little away from TDD
I find the arguments to TDD it very compelling. I find doing it very hard. It's easy to wander off the track and build things that can only be tested by running the UI or the real application environment. I've been writing a lot of SAX parsers and HTTP server stuff lately and it's tough to fake up inputs and capture outputs for verification.
It's far from impossible, and I'm making myself better at it. My point was not to whine, but to contribute to your presentation agenda - talk about some of the challenges, offer resources or examples to help get through them.
We're starting a new project soon, and giving some thought to using Dashboard to automate unit tests on every code check-in.
An "extreme" far end of the unit testing continuum you might bullet in your presentation: Never change a line of code unless you have a test that fails before and will succeed afterward. What a wonderful world it would be.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Sorry .
I'm used to hijacking threads which then starts another thread.
Perhaps JR needs a Quote and Hijack option.
regards
 
GeeCON Prague 2014
 
subject: Teaching Test Driven Development