• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to motivate team for Unit testing

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 799
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
author
Posts: 46
Python VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeff Langr wrote: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



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

 
Tim Ottinger
author
Posts: 46
Python VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


 
Ranch Hand
Posts: 149
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 12
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic