Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Sound of one man testing

Recently I was chatting with a friend of mine and he asked if a single developer could be successful following TDD on a team that does not follow TDD.  My simple answer was YES, they can.  But there are a few things you must consider.....

How can they make a difference
I am a firm believer that someone practicing Agile/TDD  can make a profound difference on a non-agile/non-testing (traditional, if you will) project. 

Following TDD is more about your mind set and attitude then it is about the process in my opinion.  Because you are following a practice that forces continuous feedback, you will actually help the team learn.  This drive for continuous feedback will be what drives new information, new knowledge to the team.

Lastly, who cares if you are on an island?  You can still make a difference. 

Does the project get the full benefits
No, but what the project does gain is light years ahead of what it would have had other wise. 

Benefits the project will gain

  • Better code coverage
    Even if you only can cover 5% of the code in your tests, that is 5% less code to worry about

  • Increased code quality
    Do I really need to explain this?

  • Increased code reliability
    Do I really need to explain this?

  • As foundation to grow on
    Because you have taking the initiate to create the test plumbing (i.e. configuration, db setup, logging setup, etc) you have reduced the barrier of entry for other developers.  I have found that this barrier of entry is a common reason people don't want to start testing.  I know it is lame, but I have heard it.

Will the team ever convert
This would be nice, but don't expect it.  However, there are a few things you can do to increase your odds.

  • Prove your code is more reliably/stable due to your tests
    This is what you tests will do.

  • Show them how easy it is
    You will be able to show then that writing tests is not hard, that it does not double the length of time to develop the new feature.  You also be able to show them how you are able to flush out uncovered bugs very early in the process, thus saving everyone time and money.

  • Show them how clean your design is
    Because your code will DO ONLY what is required, they will be impressed by how clean your code is.

  • If all that does not work, beat them over the head with a Agile/TDD book till they cave. :)

Issues to watch out for
Because you are the only one creating tests, there are things you must be willing to accept.

  • Broken Tests - Non Compiling
    Don't expect the rest of the team to include your test projects in their solution.  In the past I have received massive push back because they don't want to waste the time allowing the extra projects to build.  Because they are not building your tests, be ready to fix various compile issues from time to time.

  • Failing Tests - Compiles, but does not pass
    Because your tests are not being run on any regular basis by the other team members, just assume you are going to spend a percentage of your day fixing broken tests.

Till next time,

 

Updated some grammar mistakes, thanks Andrew :) 


Posted 02-18-2008 5:30 AM by Derik Whittaker
Filed under: , ,

[Advertisement]

Comments

» Daily Bits - February 18, 2008 Alvin Ashcraft’s Daily Geek Bits: Daily links, development, gadgets and raising rugrats. wrote » Daily Bits - February 18, 2008 Alvin Ashcraft’s Daily Geek Bits: Daily links, development, gadgets and raising rugrats.
on 02-18-2008 9:19 AM

Pingback from  » Daily Bits - February 18, 2008 Alvin Ashcraft’s Daily Geek Bits: Daily links, development, gadgets and raising rugrats.

Steven Rigney wrote re: Sound of one man testing
on 02-18-2008 11:25 PM

I love reading your posts.  and I think that one person should start adding tests when working on projects, but they need to be aware that if the rest of the team is not already testing, there may be a lot of education involved before anyone in the team starts.  I posted a blog with my thoughts at stevenrigney-tech.blogspot.com/.../testing-on-island.html

Reflective Perspective - Chris Alcock » The Morning Brew #35 wrote Reflective Perspective - Chris Alcock » The Morning Brew #35
on 02-19-2008 3:05 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #35

redsolo wrote re: Sound of one man testing
on 02-19-2008 3:50 AM

I would say that using shiny toys/tools helps in getting people to notice unit testing. I installed Hudson, a continuous integration server, which besides ran my unit tests also made sure that the trunk always could be compiled. When people noticed that the build sometimes broke (using the web ui) they fixed it themselves. Then when a unit test failed on the CI server they became aware that I was running unit tests. Then it took 2-4 months to get at least a few others on the unit test wagon.

So I would say shiny toys. But Im also a tool boy :)

Derik Whittaker wrote re: Sound of one man testing
on 02-19-2008 5:53 AM

@Redsolo,

Normally I am not a fan of doing things because it is 'new or shiny', but in this case I like it.  

If it helps to get the team testing, then I am willing to use pretty much any  new shiny toy.

Mind Gravy » Blog Archive » links for 2008-02-19 wrote Mind Gravy » Blog Archive » links for 2008-02-19
on 02-19-2008 7:28 AM

Pingback from  Mind Gravy  » Blog Archive   » links for 2008-02-19

Pages tagged "sound" wrote Pages tagged "sound"
on 02-19-2008 8:51 PM

Pingback from  Pages tagged "sound"

DotNetKicks.com wrote Sound of one man testing
on 02-20-2008 3:20 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

SeeR wrote re: Sound of one man testing
on 02-21-2008 3:49 AM

I've already tried to be the lonely TDD guy in a team and I must say that will never ever try it again.

Main problem was that after a month or some I've spent almost 30% of my time just to fix old tests. Other guys were changing code in a such way that after a while I almost created tests for their already written code, not just fixing tests. Another thing was that they spent exactly the same time on writing functionality as me, so nobody can't see the benefits of TDD.

After some time I just abandoned TDD.

Later I've changed company and now I'm working alone on projects using TDD and I must say that you can see the real benefits not earlier then something about half a year. When you introduce changes and on the presentation to user you have a peace of mind that nothing will go wrong and guess what - everything works as it should :-)

So in summary I don't recommend to be a lonely TDDer in a team, and TDD I can recommend only to projects that you suspect they can be really long one - I mean longer then few months.

Jacob Proffitt wrote Testy Development
on 02-22-2008 10:56 AM

One of the things that irks me when discussing certain technical topics is a tendency towards boosterism

Derik Whittaker wrote re: Sound of one man testing
on 02-22-2008 10:59 AM

@Jacob,

Please explain what you mean by that statement.

Troels wrote re: Sound of one man testing
on 02-29-2008 9:52 AM

I've had the same experience as SeeR. I tried guerilla-tdd, but find that I have to spend time fixing the tests, whenever some of my teammates breaks them. I don't have time for that. This basically means that I can only use the tests during the initial development phase. Once the code has been put into production, they quickly loose their value. I still do that though, but no regression-tests for me.

Andrew wrote re: Sound of one man testing
on 03-06-2008 9:23 PM

I was going to say that I found the lack of spell checking (or in some cases grammar revision) in this document to be somewhat humorous given the subject...

But then I put the various sections through Microsoft's Word spell/grammar checking and it didn't find any issues...

A perfect example of how testing can be completely useless!

[eg, "forces continues feedback" rather than "forces continuous feedback" or "forces continued feedback"

- and -

"beat them over the head with a Agile/TDD book till the cave", didn't you mean "they cave"... if not, which cave were you referring to, and do you like living there?]

http://devlicio.us/blogs/derik_whittaker/archive/2008/02/18/sound-of-one-man-testing.aspx wrote http://devlicio.us/blogs/derik_whittaker/archive/2008/02/18/sound-of-one-man-testing.aspx
on 03-27-2008 5:24 AM

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)