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
"Unit tests take too much time".... WTF

I was chatting with a buddy of mine yesterday who recently has started a new job.  His new company has built a new team to start a 'green field' project and they are currently in the 'debate' stage of planning.  The team is currently trying to decide what tools, technology, methodology, etc to use. 

One of the topics for discussion is whether they should take a TDD (or simply having unit tests) approach.  He tells me that some on his team want this while others do not.  It sounds to me from talking with him that there is not a lot of experience on his team in terms of writing unit tests.  Of course when there is not a lot of experience writing tests, it is easy to be 'swayed' by the people that don't understand the value of witting tests.  The main argument right now for NOT writing tests is.... wait for it.... wait for it.... 'Unit tests take too much time'.  All I can say to that is WTF.

It has been my experience that writing unit tests do 'take time'.  It is time you will be saving later.  It is time you will be able to spend on other things in the future.  I guess I just don't understand how educated developers can think this way. 

I would love to speak with this team, it would be great to hear all the 'excuses' they come up with.  Oh well.  Maybe someone on the team can talk some sense into them.  Or maybe after they deliver a shitty product with poor quality they will wish they had written tests.

Like the old saying says. You an lead a horse to water, but you cannot make it drink.

Till next time,


Posted 09-27-2007 7:38 AM by Derik Whittaker
Filed under: , ,

[Advertisement]

Comments

Garry Shutler wrote re: "Unit tests take too much time".... WTF
on 09-27-2007 9:16 AM

I believe the friction in this case is that when you develop in a TDD style you write all the tests and then you write all the code.

I believe that someone who hasn't got experience with TDD will think is you'll end up with the same code at the end whether you did it via TDD or not. Because at the end of the day it's the same person writing the actual code (i.e. writing the tests is just a load of extra effort for the same final product).

I think the problem is proving the difference in the quality of the code produced through TDD to people who haven't tried it and how that improvement in quality far outweighs the intial work in terms of the effort required for maintenance and modification.

on 09-27-2007 9:27 AM

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

Joe wrote re: "Unit tests take too much time".... WTF
on 09-27-2007 12:29 PM

If you're not familiar with TDD or even write-as-you-go testing and the huge productivity gains you get from this later on in the project, this attitude makes sense.  

I think people may wonder why bother if they can just fire up  the debugger if the code doesnt work.  Or they may think they arent writing anything so complicated that they cantjust eyeball it and fix it.  Or perhaps they figure that 85% of what they are doing is CRUD, and theyve read over and over again that unit testing doesnt involve touching the database, so they can probably manage that other 15% without tests.

As a related note, and this story is another piece of anecdotal evidence, I think the TDD/Agile community really falls in any efforts it makes to educate people as to why TDD (and others pillars of Agile methodologies) are good practices.  

Derik Whittaker wrote re: "Unit tests take too much time".... WTF
on 09-27-2007 2:03 PM

@Joe,

I am not sure that the Agile community is doing a bad job of educating people.  I personally think it is more that people in general are adverse to change.  Especially when the change goes against everything they have ever done.  Most developers have a 'large' ego and have the mind set that 'what i have done in the past has worked, so why change'

My 2 Cents

Markus Zywitza wrote re: "Unit tests take too much time".... WTF
on 09-28-2007 5:32 AM

The main problem with unit tests for TDD inexperienced developers is that they are not compatible with classical (waterfall) development strategies.

If you are using agile development, you'll instantly (or at least after a short time) see the benefit of unit tests, but if the first 2 or 3 months of a project are used only for creating the model and CRUD functionality, unit tests are a seemingly unnecessary burden at this time.

My opinion is to write tests where they are needed. Whenever your code has complex or unconventional behaviour, an unit test is a must have. The same is true for reported bugs to document the bug and verify that it is fixed. I am however reluctant to test get/set-behaviour of properties on a regular basis, as it violates DRY.

That said, I'm still dreaming of an IDE or addin that can automatically create such tests...

mark wrote re: "Unit tests take too much time".... WTF
on 09-28-2007 8:40 AM

I'm on a team similar to the team in your post.  We don't use TDD or write unit tests.  Why?  Because they have historically been a fabulous waste of time for all of us.  Writing our unit tests for everything nearly doubles to development effort, all so that we can save...maybe...a couple hours in QA and bug fixing.  There were no less or more bugs when we don't use TDD as when we did.  So really, whats the point?  If the code quality sans unit tests is as good as the code quality with them and the end user is ecstatically happy with the product then why waste hours that could be used providing more value to the customer.

Now...what really makes me go "WTF" are dogma preachers who think everyone who doesn't subscribe to their latest and greatest "best way" is stupid.

David Mohundro wrote re: "Unit tests take too much time".... WTF
on 09-28-2007 10:12 AM

Derek, I can relate to what you're talking about because I'm trying to get my company to buy in on TDD more. You're exactly right that people are adverse to change - not just adverse, scared of it. I'm only speaking from my own experiences, of course, but the change that has to happen to really grok TDD is the hardest part.

From the outside looking in, of course unit tests sound like more code. More code sounds like a longer time. Our users want the product yesterday. Why should I spend more time? This is the thinking I hear all the time.

What I have to fight is the "get it done" attitude... more accurately the "we'll fix the bugs later" attitude. The product isn't actually done until the bugs are fixed anyway! I can't call myself a TDD practitioner yet, but in what few examples I've tried to follow a TDD approach, the outcome was a much more stable and better product overall. I'm just having trouble explaining why the whole process worked better without saying it just feels better :)

Software Warlock » The Value of Unit Testing wrote Software Warlock » The Value of Unit Testing
on 09-28-2007 10:44 AM

Pingback from  Software Warlock » The Value of Unit Testing

Derik Whittaker wrote re: "Unit tests take too much time".... WTF
on 09-28-2007 2:44 PM

@Mark,

Writing tests does not only save you a few hours of qa time.  It does much more.  It allows you to write simpler code, it allows you to have more confidence in your code, it allows you to refactor with less chance of error and most importantly it allows you to automate the testing that you do anyway.

I have to assume that you currently have some sort of UI test harness with a ton of buttons that you use to test your code.  If you don't have one of these then i assume you run your application to do all your testing.

If you have one of these infamous test harness UI's then you essentially have your unit tests, just they are not re-runnable and no one other then you knows they exists.

mark wrote re: "Unit tests take too much time".... WTF
on 09-28-2007 5:29 PM

Derik -

In my experience the "much more" you gave me as examples are meaningless to an experienced team.

I write simple code by default, adding complexity for the sake of some dogma read on the internet is the fastest way for someone on my team to get a kick in the pants.  A new developer may not recognize when they are writing over-engineered or sloppy code but after a few years on the job you can tell when you are writing crap and unless the developer is lazy (no amount of UTs are gonna help that) they are gonna go fix it.

Confidence?  We have confidence in our application going out of the gate, if we didn't it doesn't go anywhere.  Our code works and we know it works because we have been working with it all along.

Refactoring is an overused term that people twist to mean things that it doesn't represent.  I'll assume the most general usage is meant here.  Any experienced developer with a proper design isn't going to need extensive refactoring.  If you do there was a failure in design long before unit testing ever would have solved.  Simple refactoring is a fact of life and usually painless, but if your gutting entire portions of the system then the failure goes farther back then the code.

That leaves automation.  A noble effort (and difficult to achieve depending on the system) but frankly, speaking for myself and the developers I know, if we have touched a portion of the code we run it from start to finish through the debugger to make sure that exactly what we expect to happen IS happening and if it isn't we can correct it as we see it.  Running an automated test, then going back to find the problem and fix it afterwards is complete inefficiency.  How can a developer with any self respect trust the results of an automated test on code he changed.  The automated test can and usually does miss some subtle point within the code that ends up passing the test but still causes a failure elsewhere.  I'd rather take responsibility for my code and watch what's happening to the things I've altered in realtime.

Don't get me wrong, automation is great for QA.  But that's also QA's job to figure out what is the best parts of the system to automate and what tools they want to do it.

Derik Whittaker wrote re: "Unit tests take too much time".... WTF
on 09-28-2007 9:44 PM

@Mark,

I can see we don't really see i to i on this one.  I say lets just agree to disagree.

Thanks for reading

mark wrote re: "Unit tests take too much time".... WTF
on 09-30-2007 11:12 PM

so rather then support and advocate your viewpoint you would rather blog in a condescending manner with no supportive arguments and then ignore counters with only the barest attempt to support your view?  Not much of a blog then.

Michal Talaga wrote re: "Unit tests take too much time".... WTF
on 10-01-2007 3:53 AM

The main problem with TDD is that once you discover that you need to change a concept of some part of the software in way more significant than renaming a method, it may, and it often does happen, that 90% of your tests go out of date.

Consider for example, removing a whole class hierarchy without moving the behavior elsewhere.

Paul Kohler wrote re: "Unit tests take too much time".... WTF
on 10-02-2007 7:59 AM

A few years ago I heard those words uttered in a job interview - we don't have time for unit tests... After I left that company I became a testing advocate because I saw just how much pain it could cause especially on a large, team based project. Testing huge code bases by hand is just too hard!!

Now I know better - as in thinking that's ok - you need the unit tests from a regression point of view and as far as changes are concerned, if you have good tools (such as resharper) then the issues are minor and just part of development.

The other advantage of unit tests are that they can (if done well!) document you code.

I would rather read a unit test than out dated comments, the unit test tends not to lie because it's compiled and run (where as the comments will get out of date etc). That's another issue though!!

Derik Whittaker wrote re: "Unit tests take too much time".... WTF
on 10-02-2007 8:23 AM

@Mark,

No, I choose not to try to 'convert' you if you are unwilling to listen to reason.  

Now, if you want to read about why I like and follow TDD, read my latest post -- devlicio.us/.../why-i-believe-in-and-write-unit-tests.aspx

Again, thanks for reading

mark wrote re: "Unit tests take too much time".... WTF
on 10-02-2007 7:21 PM

Derik -

Unwilling to listen to reason?  What "reason"?  You haven't offered any.  This so-called blog post was simply condescending attitude against anyone who didn't agree with what you perceive to be the benefits of TDD.  It wasn't until I dropped in as one of the supposedly ignorant crowd that you finally offered anything of substance and when I countered with my own experience you ran off in a huff.  From my perspective your the one unwilling to listen...to anything.

As for your latest post, now THAT post was much more reasonable and responsible.  At least you provided meat to back up your point of view and made it clear that it was your point of view and that the experience of others may vary.

James wrote re: "Unit tests take too much time".... WTF
on 10-09-2007 9:41 AM

My experience is that TDD provides a very methodical framework for writing small sections of tricky code. Of course it's no magic bullet, and no substitute for being a good coder. On sections of simple, easy-to-debug code I write coarser grained unit tests or use-cases. TDD is just one gun in the armoury for a specific set of problems.

Now that the project I'm working on has unexpectedly ballooned in scope, and even a minor bug will have instant repercussions on large numbers of customers, I'm glad we put the early effort into building up our test suite. Cowboy coding was fine for working in small start-ups, but I'm a convert to TDD now.

Komentuj wrote re: "Unit tests take too much time".... WTF
on 10-14-2007 6:30 PM

It's very easy. Units test do take time if you're a manager!!! People that are not developers and often put there to made the decisions and it ends that way. Why should he waste 10h of work when the developer can create 10 new features in that time even if the client complains later that sth doesn't work completely, you still can charge him for the features. It's hard to pitch the sale based on testing that cannot be done!

Komentuj wrote re: "Unit tests take too much time".... WTF
on 10-14-2007 6:30 PM

It's very easy. Units test do take time if you're a manager!!! People that are not developers and often put there to made the decisions and it ends that way. Why should he waste 10h of work when the developer can create 10 new features in that time even if the client complains later that sth doesn't work completely, you still can charge him for the features. It's hard to pitch the sale based on testing that cannot be shown!

Dave Schinkel wrote re: "Unit tests take too much time".... WTF
on 10-27-2007 1:47 AM

>>>Komentuj said:  

It's very easy. Units test do take time if you're a manager!!! People that are not developers and often put there to made the decisions and it ends that way. Why should he waste 10h of work when the developer can create 10 new features in that time even if the client complains later that sth doesn't work completely, you still can charge him for the features. It's hard to pitch the sale based on testing that cannot be done!

---------------------------------------------------------------------------

Sorry for my tone but I’m about to speak from my heart:

I AM SO TIRED OF HEARING THIS FROM WEAK MANAGERS!!!!!!!!!!!!

I'm so very sorry but Komentuj, but your reasons are simply put….WEAK.

This is the entire problem of 70% of IT departments & managers out there in this world, and thus why 70% of companies have so much turnover and loose so much money on the bottom line.  

What you just explained to me (my interpretation and conclusion based on your attitude) is that you are willing to allow a CODE-AND-RUN shop ultimately to develop within your organization and trust me, with that kind of attitude, it will.

>>> It's hard to pitch the sale based on testing that cannot be done!

Awe, poor baby.  Seriously…

>>> Why should he waste 10h of work when the developer can create 10 new features in that time even if the client complains later that sth doesn't work completely

What!?!  You’re saying code-and-run even if the *** isn’t very good at the end because all you care about is numbers basically.  Have you ever thought to yourself that maybe, just maybe if I would have allowed my developers time, we could all have a life at the end of the day rather than fixing *** all day and the business would benefit overall as a result of this?

It's called PUSH BACK!   And if you’re “scared” to do it for fear of losing your job, then maybe you shouldn’t be a manager?

Seriously, grow some balls and start telling the business no sometimes when creating that Contract and timeline.  No, I’m sorry but that’s not realistic.  I need to tack on another 3 weeks to your required date for that project so we can deliver a proper product to you.  Sometimes you don’t need to explain to them why, just tell them that your team cannot produce a quality product with those constraints.  If they get pissed, oh well….it’s called politics, business, and life.

If you don’t, I mean really, must I take time here to spell out why?

1) Your developers waste the business’s time because they have to fix each other's shitty code because their manager only cared about "getting it done quick" vs. taking some time up front to deliver a clean code base.  

This “code base” is not just for your customer but the members of your team are customers in that they consume each other’s code.  Have you ever thought this way?  If I were a manager, that would definitely always be first and foremost a thought in my head at all times.

Because some manager had no balls in the requirements and scoping meetings what happens is time is wasted.  Healthy dose of CHAOS every frigging day.  And that sucks.

2) You ultimately cause your client PROBLEMS in the end once you’ve busted out those 10 wonderful programs in 10 days (Hmm, sounds like a book, maybe I should right that).  Ok, fine they're “happy” it's DONE…. temporarily, but in about 2 weeks, they hate you again because it's a pile of ***, it's slow, it’s whatever…and now it has to go back through the development process for small stupid bugs.  Now you’ve just cost the business MORE money.  On top of that your reputation degrades as a manager over time.  

Scenario:

Fellow Teammate1:  “Hey fellow teammate1, want to go to a strip bar tonight with my friends who are visiting from CA?”

Fellow Teammate2:  “Sorry fellow teammate2, I have to sit here and fix some bugs from that app we just pushed to production”

Result:  Profound implications, you just missed going to a strip club with your buddy!  This is not fun!

3) You don't end up having to hire 10 more people to create a Production "fix" team.  That's just ass backwards and weird to me.

4) Any new developers that come to the team will ENJOY their job, therefore be motivated to come to work to produce code, not fix code!

Scenario:

New Guy: “Hey there fellow developer, who allowed the team in the past to produce this pile of ***? “

Old Guy: “ Uh, well, our manager did, we don’t have time to do things right around here”

New Guy: “ Uh why”

Old Guy: “Uh, because the business demanded it.”

New Guy: “Um….  I don’t compute what  you are saying.  Why again?”

Old Guy: “Uh, well, because the manager is just stupid and never gives us time”

Result: new guy thinks “when am I going to find another good team, seems like every place I go it’s like this.  Time to open that coffee shop I guess”

Do you want this to happen to you?

5) You don't allow your coders time to actually LEARN while they code and develop into better coders while producing those BUSINESS RESULTS.  All they are concerned about at this point is the pressure you put on them to get it done FAST because you “Had no choice, the business wants it now”.  Do you ever listen to yourself say that to someone?  I

You are a manager..Ok fine, nice.  You are in business to deliver results.  BUT wake up, you are also to make sure that you are a cushion to your team.  That the product in which you code is not just produced FAST.  I cannot stand that.  The end result of that is a pile of *** and unhappy employees.

This is the MOST troubling sentence:

I'm sorry but that's "WEAK" argument as a manager.  You as a manager ALWAYS have these pressures but it’s YOU’RE job to manage these pressures so that your team is happy, the customer is happy, and everyone can go home at the end of the day.  Taking time now, during the development, makes everything much Sunnier in now and in the long run both at work and at home because you’re not focused on “FAST” you are focused on “QUALITY”.

GET SOME BALLS in meetings and tell them sure, I can compromise, but I’m definitely not going to whip that out in the time you’re dictating to me.  

Again, there's a fine line between "Delivering fast" and "Delivering Quality".

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)