aspose file tools*
The moose likes Agile and Other Processes and the fly likes How to motivate team for Unit testing 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 "How to motivate team for Unit testing" Watch "How to motivate team for Unit testing" New topic
Author

How to motivate team for Unit testing

Shailesh Mangal
Greenhorn

Joined: Apr 09, 2006
Posts: 2
Unit testing is critical for all projects, agile and non-agile. Lack of formal QA makes it all the way more crucial for agile projects. In my experience, UT is one of the hardest things to enforce upon a team specially when there are lot of junior people who may not equal appreciation for UT as their senior counterparts. And than there are those who may agree in principle but fail in day today implementation. Business pressure to squeeze last minute feature also hurt this. Are there better ways(tools/processes) to keep team motivated to keep writing good quality/coverage UT.

-Shailesh
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Hi Shailesh,

Good question, and welcome to JavaRanch!

My first thought is that unit testing alone is painful for most developers. Usually when people say "unit testing," they mean "plain 'ol unit testing," or what I like to call test-after development. I prefer to introduce people instead to TDD--test-driven development--and then describe the differences between the two in terms of the benefits. Here are a couple blog posts on the topic:

http://langrsoft.com/jeff/2011/02/is-tdd-faster-than-tad/
http://langrsoft.com/blog/2008/07/realities-of-test-after-development-aka.html

So, step one in introducing anything to developers is that they have to be convinced that they will personally benefit from incorporating it. Unit testing along simply doesn't offer much to an individual developer, other than "my manager will can me if I don't do it." They view testing-after-the fact as simply proving something they already knew worked, for the most part.

TDD instead--done well (and it's certainly possible to not do it well, and not get these benefits)--is more enjoyable, it gives you better design, the ability to change code safely without panicking, and some level of class documentation to boot. There are other reasons to do TDD too. I talk about the myriad benefits in my 3-day TDD class, and by day 3, most people leave the class jazzed and knowing why they should be taking on TDD.

I wouldn't preach it if I didn't enjoy it and hadn't found how much it's improved my capability to develop, and develop fast.

Unit testing is a difficult way to demonstrate that some of your code works.

TDD is a disciplined approach to software development that is focused on sustaining the quality of the design and code in a system. It's also a lot of fun once you get used to it.

Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
s mangal wrote: Are there better ways(tools/processes) to keep team motivated to keep writing good quality/coverage UT.


To answer this other part of the question: It's hard to sustain most practices. Managers do tend to want to squash on anything other than "just slamming out code," which is always a bad idea (discarding quality at the time when it will probably be missed most).

Pairing can help, as it provides a little peer pressure, coupled with some social enjoyment, but that's yet another thing to sell.

Some level of helpful information radiator metrics (see our Information Radiators card) can help show the team the progress they're making toward the goal of improved quality/coverage. Be careful with metrics, though, as they can steer things in a bad direction if you're not careful.

Mostly, I think you need to help the individuals get to a point where they find TDD enjoyable and beneficial, and they know how to avoid the many pitfalls that are possible to step in.

Regards,
Jeff
Tim Ottinger
author
Ranch Hand

Joined: Jan 26, 2011
Posts: 46



Not to forget http://agileinaflash.blogspot.com/2009/02/why-pout-aka-tad-sucks.html


He writes code. He likes it.
Tim Ottinger
author
Ranch Hand

Joined: Jan 26, 2011
Posts: 46

s mangal wrote: Unit testing is critical for all projects, agile and non-agile. Lack of formal QA makes it all the way more crucial for agile projects. In my experience, UT is one of the hardest things to enforce upon a team specially when there are lot of junior people who may not equal appreciation for UT as their senior counterparts. And than there are those who may agree in principle but fail in day today implementation. Business pressure to squeeze last minute feature also hurt this. Are there better ways(tools/processes) to keep team motivated to keep writing good quality/coverage UT.

-Shailesh


I think that the key is between "keep team motivated" on one side v. "to enforce upon a team."

Typically the practice is self-sustaining and self-propagating once it's started ad people are pairing, because it makes the code so much better and saves you from making big mistakes several times a day (or at least several times a week). People start to expect it from their teammates, and they get grumpy when new code doesn't have tests.

That being said, some people won't do it. They either won't test first, won't test after, won't automate tests, or won't test at all. Often it's a matter of knowing how, but sometimes it's just stubborn refusal to learn or practice the techniques. Often people feel that testing their code is beneath them, or not worth the time to invest in doing it. They should be given a little time and exposure to the benefits of testing, but eventually they need to either get on board or find a different team to ride with.

The last-minute-feature syndrome is a different problem, but it does highlight that if you don't have good support for your team then you can get squashed. See my "platitudes of doom" write-up: http://agileotter.blogspot.com/2009/08/platitudes-of-doom.html Really short iterations are helpful if your product owners are getting "buyers remorse" and wanting to swap some hot feature in instead of waiting. That's what agile is about. Keep the iterations short enough that they don't have to wait very long to change their minds, only a week or two.


arnel nicolas
Ranch Hand

Joined: Dec 16, 2003
Posts: 149
I agree that this is more of a discipline. Maybe you can motivate the team by explaining to them the short term and long term benefit of unit testing. Site good examples if you can. Do pair programming with them and lead by example.

Or if not, enforce it to the team . What you can do is to require them to have unit test where it make sense as part of your code review process. Then that will become a practice in their day to day activities. Or as previously mentioned, establish a metric regarding code quality to measure if you are improving or not in that aspect and make it as part of your team goal.
Kristian Aaslund
Greenhorn

Joined: Jul 21, 2011
Posts: 8
arnel nicolas wrote:I agree that this is more of a discipline. Maybe you can motivate the team by explaining to them the short term and long term benefit of unit testing. Site good examples if you can. Do pair programming with them and lead by example.

I think working test-driven and writing good unit tests is a mindset, not a discipline. I totally agree on leading by example. Show them how it's done. Show that simple tests may cover a lot of the functionality and prevent regressions. Many developers think that they should test every possibility in every method. That is too time consuming. The TDD mindset will help you identify where a unit test is needed and how much testing is needed. Pair programming also works if at least one of the two has some experience in writing good tests.

arnel nicolas wrote:Or if not, enforce it to the team . What you can do is to require them to have unit test where it make sense as part of your code review process. Then that will become a practice in their day to day activities. Or as previously mentioned, establish a metric regarding code quality to measure if you are improving or not in that aspect and make it as part of your team goal.

I hate enforcement. We should want to follow best practices, not be required to. Demonstrate TDD on a regular basis and focus on simplicity and how to save time. Take time to help developers that struggle with the mindset or technical issues. It is better that all developers gets a little better at writing tests than one guy becoming a supernatural TDD ninja.
Anirudh Bhatnagr
Greenhorn

Joined: Sep 01, 2010
Posts: 12
Coercion is so anti-agile.

One need to feel the need of something to actually do it.

I would say TDD is a convenience which we attain by discipline.

Coach the team with the benefits of unit-tests, forcing will totally be a disaster.

Make a playful plan- put rewards- its all about how you coach for Agile mindset.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to motivate team for Unit testing
 
Similar Threads
Java guru's wanted that love open source projects
books for software quality control and assurance
Test Driven - testing with multiple teams
Agile Testing - a new strategy being applied?
Agile Testing = Test first in Agile Projects?