Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

Programmers Without TDD Will be Unemployable by 2022

  • submit to reddit
New year is traditionally the time of predictions, and several of the blogs I read have been engaging in predictions (e.g. Ian Sommerville “Software Engineerng looking forward 20 years.”). This is not a tradition I usually engage in myself but for once I’d like to make one. (I’ll get back to software economics next time, I need to make some conclusions.)

Actually, this is not a new prediction, it is a prediction I’ve been making verbally for a couple of years but I’ve never put it on the record so here goes:
By 2022 it will be not be possible to get a professional programming job if you do not practice TDD routinely.
I started making this prediction a couple of years ago when I said: “In ten years time”, sometimes when I’ve repeated the prediction I’ve stuck to 10-years, other times I’ve compensated and said 9-years or 8-years. I might be out slightly - if anything I think it will happen sooner rather than later, 2022 might be conservative.

By TDD I mean Test Driven Development - also called Test First (or Design Driven) Development. This might be Classic/Chicago-TDD, London-School-TDD or Dan North style Behaviour Driven Development. Broadly speaking the same skills and similar tools are involved although there are significant differences, i.e. if you don’t have the ability to do TDD you can’t do BDD, but there is more to BDD than to TDD.

The characteristics I am concerned with are:
  • Developer written automated unit test, e.g. if you write Java code you write unit tests in Java... or Ruby, or some other computer language
  • The automated unit tests are executed routinely, at least every day
This probably means refactoring, although as I’ve heard Jason Gorman point out: interest in refactoring training is far less than that in TDD training.

I’d like to think that TDD as standard - especially London School - also implies more delayed design decisions but I’m not sure this will follow through. In part that is because there is a cadre of “designers” (senior developers, older developers, often with the title “architect”) who are happy to talk, and possibly do, “design” but would not denigrate themselves to write code. Until we fix our career model big up front design is here to stay. (Another blog entry I must write one day...) 

I’m not making any predictions about the quality of the TDD undertaken. Like programming in general I expect the best will be truly excellent, while the bulk will be at best medicare.

What I am claiming is:
  • It will not be acceptable to question TDD in an interview. It will be so accepted that anyone doesn’t know what TDD is, who can’t use TDD in an exercise or who claims “I don’t do TDD because its a waste of time” or “TDD is unproven” will not get the job. (I already know companies where this is the case, I expect it to be universal by 2022.)
  • Programmers will once again be expected to write unit tests for their work. (Before the home computer revolution I believe most professional programmers actually did this. My generation didn’t.)
  • Unit testing will be overwhelmingly automated. Manual testing is a sin. Manual unit testing doubly so.
And I believe, in general, software will be better (fewer bugs, more maintainable) as a result of these changes, and as a result programmer productivity will be generally higher (even if they write less code they will have fewer bugs to fix.)

Why do I feel confident in making this prediction?

 Exactly because of those last points: with any form of TDD in place the number of code bugs is reduced, maintainability is enhanced and productivity is increased. These are benefits both programmers and businesses want.

The timescale I suggest is purely intuition, this might happen before 2022 or it might happen after. I’m one of the worst people to ask because of my work I overwhelmingly see companies that don’t do this but would benefit from doing it - and if they listen to the advice they are paying me for they start doing it.

However I believe we are rapidly approaching “the tipping point”. Once TDD as standard reaches a certain critical mass it will become the norm, even those companies that don’t actively choose to do it will find that their programmers start doing it as simple professionalism.

A more interesting question to ask is: What does this mean? What are the implications?

Right now I think the industry is undergoing a major skills overhaul as all the programmers out there who don’t know how to do TDD learn how to do it. As TDD is a testable skill it is very easy to tell who has done it/can do it, and who just decided to “sex up” their CV/Resume. (This is unlike Agile in general where it is very difficult to tell who actually understand it and who has just read a book or two.)

In the next few years I think there will be plenty of work for those offering TDD training and coaching - I regularly get enquiries about C++ TDD, less so about other languages but TDD and TDD training is more widespread there. The work won’t dry up but it will change from being “Introduction to TDD” to “Improving TDD” and “Advanced TDD” style courses.

A bigger hit is going to be on Universities and other Colleges which claim to teach programming. Almost all the recent graduates I meet have not been taught TDD at all. If TDD has even been mentioned then they are ahead of the game. I do meet a few who have been taught to programme this way but they are few and far between.

Simply: if Colleges don’t teach TDD as part of programming courses their graduates aren’t going to employable, that will make the colleges less attractive to good students.

Unfortunately I also predict that it won’t be until colleges see their students can’t get jobs that colleges sit up and take notice.

If you are a potential student looking to study Computer Science/Software Engineering at College I recommend you ignore any college that does not teach programming with TDD. If you are a college looking to produce employable programmers from your IT course I recommend you embrace TDD as fast as possible - it will give you an advantage in recruiting students now, and give your students an advantage finding work.

(If you are a University or College that claims to run an “Agile” module then make sure teach TDD - yes, I’m thinking of one in particular, its kind of embarrassing, Ric.)

And if you are a University which still believes that your Computer Science students don’t really need to programme - because they are scientists, logisticians, mathematicians and shouldn’t be programming at all then make sure you write this in big red letters on your prospectus.

In business simply doing TDD, especially done well, will over time fix a lot of the day-to-day issues software companies and corporate IT have, the supply side will be improved. However unless companies address the supply side they won’t actually see much of this benefit, if anything things will get worse (read my software demand curve analysis or wait for the next posts on software economics.)

Finally, debuggers are going to be less important, good use of TDD removes most of the need for a debugger (thats where the time comes from), which means IDEs will be less important, which means the developers tool market is going to change.
Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


darryl west replied on Fri, 2014/01/17 - 11:47pm

I am disappointed by all the negative comments that this post has received.  But not too surprised.  As a manager, I will not hire any programmer, junior or senior that isn't completely on board and can demonstrate engineering experience with TDD.  Otherwise, I'm wasting my time with a second-rate, crap coder.  

When challenged on my TDD requirements, I hear the same lame excuses as the ass-hat comments above about how "management won't budget it" or "I just don't have the time".  What a load of shit.

If it's worth doing, then do it right.  It only seems faster to do it the wrong way--but it's not.  Doing it right means knowing that it works.  Knowing that it works means testing it--100%.  Anything less is crap.

So thank you Allen for your great post.  Hopefully the script kitties that disagree with your assertions will seek employment in a less demanding industry.

By the way, TDD isn't new.  Do some research on the AWK development team from 1977.  

Oleksandr Alesinskyy replied on Sun, 2014/01/19 - 6:11am in response to: darryl west

As most participants of this discussion you simply do not understand what you are speaking about.

  1. TDD is not about "to test  it not to test" - it is about writing tests before code under tests and (at least in its classical form) doing it in very small increments (just to satisfy a single test only).
  2. 100% testing is neither possible (due to the 2**N curse - good design may substantially alleviate it but can't lift it completely), nor feasible (in most cases it is plainly stupid to test code for which tests will be more complicated - and so more error-prune - than the code itself).

Allan Kelly replied on Sun, 2014/01/19 - 5:36am in response to: darryl west

Thanks Darryl,

I couldn't have said it better myself!

I think you've put your finger on something here, something I'll have to follow up in a later blog.  In my experience, when presented with a coherent argument most managers get it.  As I said, this deserves more discussion, another blog


Stephen Hosking replied on Mon, 2014/01/20 - 3:35pm in response to: Loren Kratzke

Loren, I'm working on a great tool which does all this! 

I remember 20 years ago someone telling me that all these methodologies were just an excuse to avoid code  (back then it was 4GLs, and CASE). He has been proven wrong so many times, and I'm going to prove him wrong again.

In the meantime, I am still finding some use for code. It often helps to debug the tests.

Dave Beck replied on Mon, 2014/01/20 - 5:37pm in response to: Allan Kelly


You can and you DID say it better yourself.

As the commentary illustrates, many devs are not working in that kind of shop.  Sure they can go find a better shop if they want to and many do, but it may surprise you to find that many folks (even some really smart ones!) don't subscribe to a one-paradigm-to-rule-them-all ideology!  Has it occurred to you that some really great software has been made by individuals/teams that didn't practice TDD?

It doesn't take smart people too long to conclude that team culture and individuals' affinity toward their teammates and managers has an impact on delivery and quality that is an order of magnitude greater than any technology or process decision ever could.

I'd wager money that most devs would prefer to work in a somewhat technologically or procedurally-backwards shop than work for a self-aggrandizing blowhard who is insecure enough in their own worth so as to erupt with insults and vitriol at random strangers on the internet for expressing a semi-contrary viewpoint.  I don't think it's any coincidence that the smartest/best developers that I've come across in my journeys did great work regardless of the methodology (and often in spite of it) and also were the least likely to have to stoop to tearing others down to make themselves feel better.  To the contrary, the best developers I've come across are able to mentor without disparaging, can exhibit patience even when they know they are right and are humble enough to be able to learn from anybody who has a great idea.

Frankly, I'm disappointed that you overlook these basic concepts to high-five someone who insults a good proportion of your reader-base simply because he supports your premise.  Good luck with that next blog post!


Terry Pearson replied on Wed, 2014/01/29 - 12:25pm

I will have to politely disagree with your prediction. Your observation that testing is important is spot on, but I do not believe testing will be a priority, ever. I've worked on systems in large financial institutions and smaller companies.

My observation is that the larger institutions talk the talk, but have trouble walking the walk here. I think it is a combination of leadership that will not budget extra time for testing and developers who put it off to keep their project hours under control.  I also think that scope creep and uncertain specification play a great role in this.

Now, in a perfectly logical and rational world, TDD would be used and thought of immediately. But, that is not usually the case. Too many people get moved around, pressured to cut their budgets, etc and management fails to see the long term importance of such procedures. 

Some companies do see the value here and are a pleasure to work for. However, this will never be as main stream as what would seem logical. There are just too many office politics / human factors for companies (especially large ones) to always make this a priority.

Allan Kelly replied on Thu, 2014/01/30 - 4:25am

 Good points. (A reply to Dave Beck).

You bring us back to the "people or the system" argument. I have heard many people say "its the people" and I agree with them, and I've read Deming and he say "its 98% the system" and I agree with him. I think the whole industry is stuck in this double-think.

Let me suggest that the best programmers gravitate towards TDD, OK, its my opinion, but all the programmers I respect practice it.  It may be that doing TDD is a filter. Or it may be that the best people conclude that it is effective.

Unraveling cause and effect here is beyond me.

Oleksandr Alesinskyy replied on Thu, 2014/01/30 - 7:10am in response to: Allan Kelly

My opinion and (30+ years of) experience is exactly opposite to yours - best developers heavily gravitate toward automated testing, but strive to stay clear of TDD (after some trial runs).  But this is not an hard rule - there always will be developers with a mindset well--suited for TDD (and there is nothing wrong with it).

Peter Verhas replied on Fri, 2014/01/31 - 5:54am

By 2022 any programmer who have never heard about TDD will easily get job so long as long they can program in COBOL.

You think this is a joke. Actually it is, but as many jokes, you can have a look at it from the other side and take it serious. COBOL can be just any legacy knowledge.

Rob Mitchell replied on Fri, 2014/02/14 - 7:16am

Over 27+ years, I've seen the software engineering fads come and go, but I have to admin that I do like most of the TDD concepts and, yes, I do take a test-first approach to most of my efforts. I push my fellow Java nerds to think/do write JUnit tests first before they embark on their agile tasks. All this is wrapped-up in automation to make our lives better. As far employability? Yeah, I actually ask interviewing candidates how they go about developing solutions and finding bugs and fixing things. If I don't hear the magic "unit testing" or "black box" or "white box" etc - then we're not on the same pattern and this will be a problem. There's so many things to pick and choose, just be smart and choose what works for you and your organization.

Jeff Salter replied on Thu, 2014/02/20 - 7:10pm

I am on a project which, during it's "R1" (release one), we worked with Thoughtworks.  They had 2-3 developers on site, who would pair with my company's developers (including me), with 12 off site developers (in Pune, India).  We did full Agile/Scrum, with sprints and user stories, and almost every development story had pair programming (except for the smallest of stories).  Each pair would include one dev from Thoughtworks, and one from my company.  It was very valuable experience to see how Thoughtworks did things, and learn from it.

Anyway, of the 3 different Thoughtworks developers I worked with (each of which was a "Senior Developer" with many years with Thoughtworks), only one of them ever practiced TDD, and even he only did it for, at best, half of the time.  The other guys would just write the code first, test it manually, review it (in volleyball sessions) with the business analyst, product owner, and project manager, and after it was agreed on that the story was doing what it needed to do and do it an efficient manner and with a good end user experience, only then would the unit tests be written (with any necessary re-factoring done). Then the story would be pushed to UAT, and QA would get it's hands on it (manual, human testers), and they would also use their own automated smoke tests.   I found this process to be very very fluid and productive, and produced very very good code and made all the stakeholders happy.

The one guy who did practice TDD (writing the tests first) had been doing it for years (immediately upon hire at Thoughtworks).  He was really really good at it, and he brought me up to speed on it pretty quickly, and he was a brilliant programmer.  But in working with him during these TDD sessions, I found the process to go much slower, and the proper design and results that made the stakeholders happy, to happen much more awkwardly, and the code would sometimes have to be re-factored later because it really wasn't doing what it needed to be doing, or doing it very well.

So, long story short, in my very real world experience in working directly with Thoughtworks senior developers (and Thoughtworks are experts and huge proponents of TDD and Agile), only 1 in 3 did actual TDD, and he only did it half the time (even though he was expert at it), and the results weren't as good as when TDD wasn't used.

So what does this anecdotal evidence tell you?  Quite simply that TDD is probably better in theory than in practice.

And some other valid points made by others:

Software development is an Art and a Science.  It's not an assembly line.  Great communication, great problem solving, and creativity will always produce better software than any one particular design pattern or development/project technique.  All these things are merely tools in the toolbox, to be used when appropriate.  They are a means to an end, not the end itself.

TDD can enforce bugs, because it is design by assumption.  When you start off with requirements and then a design, you only have an idea of how to make it work well.  You don't know for sure until you actually do it, then you can learn from mistakes and course correct, and improve the design iteratively.  Then you know you have something good, and then you can confidently tell the automated tests what to expect.  

TDD can cause performance and security issues.  To make code "unit testable", it has to be broken down to smallest of classes, to the nth degree, and dependencies have to granted some sort of public access (public member, or getters/setters, or DI, etc), so they can be mocked for the unit tests.  These things can cause both code bloat and security holes, if you're not very very careful.

TDD, and any kind of unit testing, is a cost.  For any code coverage meeting recommended amounts (say, 80+%), at the very least it doubles development time (sometimes much more).  This is a cost that management has to buy into, and it has to be factored into delivery dates.  It's great when management buys into it, and even better when they actually put their money where their mouth is.  But in the real world, with limited resources, limited time, competitive pressures, and just corporate politics, the allocation of such needed resources suffers, even with the best of intentions.  TDD and any automated testing, is a cost, with benefits.  The question is, what is the true result of an honest cost/benefit analysis.  At one class I went to (that my employer sent me to), the instructor said unit testing caused a 70% reduction in bugs (and that was only SWAG).  But with a minimal 100% increase in development time, it sounds like a loss, not a gain.

Allan Kelly replied on Fri, 2014/02/21 - 5:08am in response to: Jeff Salter

Thanks Jeff, that story is most illuminating.

One thing that intrigues me is: what was the bug count like?

Both overall and from the different developers, did the one who practices TDD religiously have a significantly different number is issues to those who didn't?

You said the TDD'ed code was slower to write, I would argue that while code may well be slower to write initially it will be faster to complete, i.e. clear testing and need less rework, and this will save time and money when it is deployed.  Again it would be good to know more about this case.

What I take from the story is this: even those who practices it less often knew how to do it, they made a (hopefully) informed choice of when to do it and when not.

To me, this is what we want: there may well be occasions when it makes sense to not do things test first but that decision can only be informed when those doing the work understand the options and are capable of proceeding by either route.

My objection is when developers say: "This code can't/shouldn't be done test first" without really understanding what is involved.

Oleksandr Alesinskyy replied on Fri, 2014/02/21 - 5:39am in response to: Allan Kelly

I would rather tell another real-world story. We (a team of 14, distributed over 2 locations in different countries) developed and evolved for 3 years a rather complex project - without any TDD but with a decent automated testing. For these years only 7 bugs have reached production and none of them was classified higher as Minor - in the Critical, Major, Medium, Minor, None (AKA pure cosmetic) classification.

Does such rate satisfy you?

Dave Lopez replied on Wed, 2014/02/26 - 12:56pm

 I'm not buying into TDD.  I'm sure some people fine it useful some of the time, but I very much doubt that it's productive all of the time for all the user stories that call for integrating with existing code. 

I found the story of the thoughtworks consultants very interesting.  In practice, the agile consultants come in talking the talk, but don't actually walk the walk.  I'm not surprised.  Frankly, I think the days of agile consultants coming in and selling new and shiny things is coming to an end.  We've chased out a couple after they couldn't back up their bullshit talk.

Automated testing is obviously very important, but TDD and Unit testing seem to be way overemphasized over functional/integration testing.  The premise of unit testing seems flawed.  It seems to presuppose that your objects work in isolation.

Don't get me wrong.  I'm open to new ideas, but the TDD work I've seen have resulted in very low productivity and bizarre APIs to say the least.

Let's face it.  We're still in the stone ages when it comes to developing software and TDD/Unit testing are no silver bullets.

Allan Kelly replied on Wed, 2014/02/26 - 1:51pm in response to: Oleksandr Alesinskyy


Well done - would love to know more

Dean Schulze replied on Sat, 2014/03/22 - 6:00pm in response to: darryl west

Darryl - If developers who don't use TDD are "second rate, crap coders" please explain why you consider Linus Torvalds and Peter Norvig to be second rate crap coders.

darryl west replied on Mon, 2014/03/24 - 10:33pm in response to: Dean Schulze

hi Dean--very good point.  I would include in that group Bill Gates, Steve Jobs, Dr. Codd and, dare I say Donald Knuth--my personal programming hero--none of them were big fans of unit testing.

So let me revise and extend my remarks: for typical application programmers, unit tests are vital.  This may or may not be ignored by the programming gods.  So Dean, if your level of skill (or marketing prowess)  matches any of the above people, then ignore my comments.  The fact that you are reading this now, I can safely assume that you don't quite qualify. 

But the decision is yours.  Test and succeed.  Or, find a better way--who cares?  As a manager I won't be hiring anyone who doesn't regard testing as the highest priority.

Good luck in your career.  All I ask is that you do good work.  For some, tests prove it, but good code stands on it's own.

Dave Glasser replied on Fri, 2014/05/02 - 2:49pm

 Here's my prediction: In 2022, anyone who is capable of producing well-crafted software at a reasonable speed will be as employable as they are today, regardless of what flavor-of-the-week methodology they may or may not use.

I also predict that in 2022, people will still make bold, categorical predictions about the future of software development, just like they have for decades. And as it's been for decades, the timeframes for these predictions will be far enough into the future that no one will remember the predictions if they fail to come true, as they usually do, and there will be enough wiggle room in the timeframes so that the predictor can claim, if called on it, "I wasn't wrong, it's going to happen, it just hasn't happened yet."

Marc Ly replied on Sun, 2014/05/11 - 12:13am in response to: Dave Glasser

 Seriously, I really doubt TDD will even barely be generalized as a development pratice and "method" in 2022. Don't get me wrong, I hope for that since I'm convinced by the advantage to do such a thing.

What I see is that resistance to change is a big issue ever. Take for example a TDD practitionner that only use TDD but don't really follow it in its principles... he's really not doing TDD right, but how can you tell from first sight?

Now the real problem I think is that all of that technique constitute a new philosophy that is coming from the professional era but has to be stabilized through formation: of professionals themselves but also students. Now it is not sufficient that a program is added for student to grasp TDD practice because the teachers themselves have to change, be convinced and master the technique themselves first.

That may take a whole generation of teachers... that is roughly 20 to 45 years before a whole new generations of teachers comes. I might be wrong but at first, students, even formed, will be badly formed and that will hurt the TDD itself delaying the moment it may generalizes in the professional era.

Finally, I might say that everytime there's a way to do something (the TDD way for example), there is alas also the other way = not-TDD. Hoping that TDD will be admitted as a generalized practice doesn't make any change at all when it comes to convince the one that really don't beleive in it.

And nobody has proved that TDD is necessary. Alas.

Dave Glasser replied on Sun, 2014/05/11 - 10:34am in response to: Marc Ly

 "And nobody has proved that TDD is necessary. Alas."

In fact, it has been proven many, many times over the years that TDD is not necessary. Witness the countless examples of excellent software that have been produced without TDD. Anyone who has been active in software development for any significant amount of time knows this. That's why the thesis of this article is laughably ridiculous. Students or non-technical managers may buy into this claptrap, but there will never be enough actual developers buy into it that the author's prediction will ever come true. He should be embarrassed for having said it.

Dave Glasser replied on Sun, 2014/05/11 - 11:30am in response to: Allan Kelly

Let me suggest that the best programmers gravitate towards TDD, OK, its my opinion, but all the programmers I respect practice it. It may be that doing TDD is a filter. Or it may be that the best people conclude that it is effective.

To my knowledge, the Linux operating system was not developed with TDD. Do you not respect the programmers who developed it?

Marc Ly replied on Fri, 2014/05/23 - 7:55pm in response to: Dave Glasser

Yes, you are absolutely right Dave. I got misled in my flow of sentences...

What I meant by saying "nobody has proven that TDD is necessary" is that "nobody proved that TDD is necessary in the field of 'always' changing software" with the background idea of the "stability" of time consumption: in other words, growing project does not mean exponentially growing consumption of resources (CPU, time etc.).

For sure TDD is not necessary for lots of, and I will also say almost any, software since almost anybody really practice full TDD ^_^... that's a fact.

"Necessary" is really misleading. Sorry for the term... I really meant "really more advantageous".

Oh... about linux kernel for example...
I really personnally have no opinion about these people since I don't know them nor their real work. But I heard something about testing the kernel: that person said "it's impossible to test the kernel" and I do believe that if not possible, it is hell! and so difficult that it must probably corrupt the integrity of the test.
Now, for part of the kernel, again without any specific knowledge of that, drivers can be tested since an API exists, since functionalities and requierements are present.
But tests, anyway, does not mean TDD and I wonder what TDD can "add" to a software like an OS kernel. If somebody has any feedback and want to share, that would be great.

What I can say is that I do respect even those who proclame the unusefullness of the TDD and even agility, if their pratices produce good enough software or better in a "correct" amont of time and pain.
Now there a lot of "talk" about agility here and I won't get into detail since it is not the subject.

Dave Glasser replied on Sat, 2014/05/24 - 8:51am in response to: Marc Ly

"Advantage" is a better term for TDD advocates to use because its meaning can be highly subjective.

I still don't think it's advantageous at all. A lot of people who advocate it talk about how it helps them overcome their own particular weaknesses in thinking or designing, for example:

But not all people find writing software as difficult as Kent Beck does, as he describes in that post. If writing tests that he knows will fail initially helps him work around his infirmities, then by all means that's what he should do. But preaching that everyone should do it is ridiculous.

Marc Ly replied on Fri, 2014/05/30 - 10:39pm in response to: Dave Glasser

 Hey Dave,

     The URL you gave is a reference to the "RIP TDD" right? I remember reading an answer written by Uncle BOB (Robert C. Martin) about it, and TDD is really not dead. Just a "troll".

     More recently, well actually the thing is in progress, Martin Fowler and Kent Beck are answering to the questions (and "opposition") the guy that made ruby-on-rails raises. These videos are called "Is TDD Dead" and there are four parts for the moment.

     The three of them tackle the "problematic" aspect of not only TDD but what's behind the term.

     I, myself, cannot be objective about that discussion ; first because of my level of TDD but mainly because I see so much advantage to it that I'm still exploring... since any difficulty is a good place for me to think about the development process in general. That is exactly what TDD brings to me: an opportunity to get distance from what I'm doing and "analyze the problem", the way I'm trying to solve it.

     The only objective aspect I can tell about TDD is that (and I probably will repeat myself from other previous posts) = the only single technique that brings so much in quality and quantity when talking about code (thus development)... that are:

1) leading and directing your code (not architecturing)... you are the architecture! you have to choose and decide at each step. But then, when choice is made, tests help you get focus... and helps making your production code better by emphazing the use of good technique before bad ones...

2) the whole bunch of tests are a kind of trigger that helps you know very quickly (and also automatically) that what you've just add (some code) is breaking all of what you already did or not. It doesn't mean that the new code is bad if it breaks a test... it does only mean "hey, you may check that further now or abandon and revert that small code you've just add"...

3) in some way, part of the tests constitute one of the best form of documentation: not that readable always but never obsolete.

4) the whole bunch of tests also help you communicate with other people (developers)... just like any other code (and tests are also code), we, as developpers, always end-up reading code somehow ; so also end-up reading tests. But tests are made easy, simplistic and readable ; "faster" is acceptable only when the readibility is not affected.

5) the bunch of tests finally constitute a "harness" or a security web" that reduces the damage an error can produce. But an error can always occur, that will be a good idea then to add a test to cover "that" new special case. Time after time, your tests become really better altogether.

I cannot speak much more about tests here and TDD in particular but the specialists goes into so much details, I really don't see why we ask ourselves "why TDD?". They answer that question without saying: "YOU MUST TDD!" ^_^... it's up to you and the situation.

Now, there are times your cannot do TDD... for example when it is a too expensive considering what you have to code. Clearly a code (program) that you write only for one use or that you will throw away doesn't need TDD at all. But even in that case, if the TDD helps you go faster or better, why not.

TDD is only a tool and it is not the ONLY tool but it has so many advantages that I really see the difference when I code with and without it. One of the main advantage is that it gives me a relatively "peace of mind", not confidence! TDD gives me a way not to waste my time testing by hand few things by myself when by a click, I can test "everything" without doing more than that click.

Personnally, I'm trying to see how I can mix TDD with Wishful thinking and Developping with contracts. I don't know yet if it's a good way to go... still experimenting.

Dave Glasser replied on Sat, 2014/05/31 - 11:02am in response to: Marc Ly


You missed my point entirely, I'm afraid.

So many TDD advocates talk about how it helps them think, visualize, analyze, avoid pitfalls, etc. etc. etc. But none of the things they describe ever resonate for me. For example, Kent Beck saying:

" help me solve many of my problems during programming: 

- Over-engineering. I have a tendency to "throw in" functionality I "know" I'm "going to need". Making one red test green (along with the list of future tests) helps me implement just enough. I need to find a new way to stay focused."

Beck is describing mental struggles that he encounters during programming, like the rookie mistake of over-engineering and staying focused. And if TDD helps him overcome those obstacles, that's well and good.

But I don't have the problems that Beck has. My mental processes in designing and coding differ greatly from Beck's. For me, TDD would not produce benefits in excess of its enormous opportunity cost.

And none of the benefits you say TDD gives you resonate with me either. I'm not saying your claims are false, just that what helps you do a better job developing software will not necessarily help all other developers.

I don't object to people doing TDD, if that's what they want to do. But it's become a quasi-religion with a bunch of wild-eyed true believers who think that those who don't share their beliefs are doing it wrong. This post (the original one, not yours) is an example of what I'm talking about. It's ridiculous from beginning to end.

Marc Ly replied on Sun, 2014/06/08 - 5:59pm in response to: Dave Glasser

 Hi Dave,

     Stated like that, I understand that was not your point. And I agree with you about the original post... ridiculous :).

     About Kent BECK, I cannot speak for him but I think I know why he talks like that ;).

     Please, give TDD a try, a real try (that takes months) and make a feedback after that ^_^.

Dave Glasser replied on Sun, 2014/06/08 - 10:39pm in response to: Marc Ly

Please, give TDD a try, a real try (that takes months) and make a feedback after that ^_^.

Marc, thanks for the advice, but I won't be trying TDD any time soon. Especially not for a period of months. I can't afford to waste that much time engaging in activities that I would find boring, as well as wasteful. The benefits that TDD advocates claim it gives them, I can get without it. I would rather spend the time and effort coding new functionality, rather than pointless red/green tests for trivial code. You may find this hard to believe, but for years, I have been refactoring mercilessly, with confidence, without TDD! The way a lot of TDD advocates talk, it seems they view refactoring code as some scary, risky, difficult activity, but I do it all the time, without breaking things. It's no big deal to me.

I generally don't get into debates about the merits of TDD. As I've already said, if it helps you write better software, then you should do it.

The only reason I responded to this post is that I found the author's prediction so over-the-top ridiculous that I felt compelled to respond.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.