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.

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

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.  

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...

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.

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 :)

Pingback from  Software Warlock » The Value of Unit Testing

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.

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.

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.

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 -

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.

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.

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!

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!

>>>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".