Why doesn't some of you write unit test?

I have educated over 1000 developers the last 1 1/2 year and about 5% of them raise their hands when I ask them if they writes test, like unit test or if they use Test Driven Development (TDD). 5%! That is not much. When I asked them why they didn't write any tests, the answer is often, we should but don't have time to do it, some answer "we have test but no one maintain the test and update them".

"Test code is just as important as production code." - Robert C. Martin "Clean Code".

If you don't have any unit test, you will spend more time to test your changes (probably manually by using the applications user interface). When you need to do changes to your production code you must make sure your changes work, and all other part of the system will still work after the changes. Most of you would probably not even change existing code because of being afraid to "destroy" something. In this case you add more code that will mostly make the code smell and sooner or later rot. WIth a test in place, you don't need to be afraid of changes, it will make it easier to maintain your application. The interest of writing clean code among developer have increased lately, have in mind that writing unit test is writing code, and that code is also important to have clean. If it's not clean, people will sooner or later not maintain it, it will be harder to change and will rot. When a test start to rot, the production code will also start to rot. There aren't any excuses to skip unit test, or?

19 Comments

  • I also find this weird. Although I do not do a lot of educating, in my role as a consultant I get in touch with many developers - both in-house developers and consultants - and surprisingly few make use of unit tests or other testing frameworks. It happens that I meet developers that are not even familiar with the concept, and this I find particularly strange. All I can do then is to take my responsibility, spread the word and teach them. After all, that's one of the reasons I work as a consultant.

  • "Stupidity and lack of experience" -- Are we talking software here or religion? Unsubscribed from your feed today. May you learn in life how to influence and persuade. Good Luck.


  • @bobm:
    This is not about religion. But I assume the word Stupidity was the wrong word to use. So sorry if you took it personally, my only excuse is that English isn't my first/main language. The goal with the last sentence was something like this: "If you skip unit test even if you know about them and know about the result of using them is sad. If you don't use unit test can also be based on experiance where developers never heard about unit test or how to write or use them".

  • I have never seen any "real" unit tests so I cant say that they do help anything.
    what i mean is that the tests i have seen written by tdd "fanatics" is more or less waist of time and money. there is no idea to test if 1+1 = 2  or if "1980-01-01" is a date.
    And doing test on real data that moves overtime and has state that differ over time and value, is more or less just not worth the effort since it takes to much time to write the test. You know in the realworld someone is paying for the result not what you think is cool or great to develope.
    So why the F dont you tdd guys show us real unittest, maybe then the rest of the world will start doing it.

  • I'm a silverlight developer and i'm trying to start writing more tests. However, the difficulty i'm facing is that the app i'm writing is very data-driven. The data is constantly changing. This makes it very difficult (unless i'm totally missing something) to write tests against because the expected result from function X today might be different than tomorrow. After each release, i restore my development sql db from my live one so i can develope against current data. If you have any tips as to how to get around this, please let me know. I understand silverlight has an great unit test framework and i'd like to start using it. I just need to figure out how to get around this issue. Thanks in advance, -Ryan (rvanderkooy@ecomsystems.com)

  • I think it is the difference between theory and reality. In theory, TDD is great. You know your code works, and you know you can make changes. In reality, once you get past simple "1+1" functions, it becomes exceedingly difficult to construct complete tests. Difficulty shouldn't be a deterrent, of course, but most programmers are human*, so we are tempted to skip the really hard stuff in order to get the project done on time.

    Not a good excuse, but I think it is at least somewhat accurate.

    * For the record, I have met programmers who I am pretty sure are some sort of cyborg

  • I believe the problem has lot to do with how the idea is being sold. I'm not yet fully in the TDD group, but I'm craving to be convinced. Although the TDD folks have been doing a slightly better job lately there is still a communication gap. Most of us who haven't jumped the ship would love to be convinced with comprehensible example, not just lecturing and abstract reasoning. We need to see real life examples of how using tests improves our lives, and also how those tests should be implemented. If you need to write several pages explaining TDD without getting into the details of how to do it and why it's beneficial you've already lost. More and more people will eventually use TDD, the pace we're converted really depends on how well you guys sell us the benefits.

  • The only reason I haven't been using TDD or any unit tests is because when I look at samples of unit tests, they all make sense, but when I get to my code (Existing ASP.NET application with new features constantly added), I can never seem to get a grasp on what tests to write or how to write them. Granted I haven't spent a lot of time reading up on TDD but what usually happens is that my test code ends up a lot like the actual piece of code I'm testing which I know doesn't make sense.

    What good online sources of TDD examples/tutorials would you reccommend?

  • well i dont' know how... and I'm the smartest idiot in my office.

  • Most my code is client-server and testing that is a pain on how to setup a database, clear it, recreate it, run tests... takes too long.

    Otherwise I have to create fake data, which isn't then even really testing what I expect to see.

    I like the idea... but this part of testing is only half-baked from the solutions I've seen

  • It's Kent Beck, not Kevin Beck.

    Writing unit tests is more challenging in the real world than in Kent's book, mostly because, at least in the .NET world, we are dependent on chunks of proprietary closed source code that do not lend themselves well to writing isolated tests. It is not so "simple" to replace "real" data access code with fake code.

    Also, you'll find in the real world that people are a lot less rigorous about their code. Whether it is time constraints, cost constraints, ignorance, or laziness is irrelevant. Testing, which has a high barrier of entry when it comes to cost, time, and learning curve, is harder to adopt than good commenting, refactoring, or even basic code hygiene. I understand that the payoff for unit testing may be worth the effort, but it's difficult to convince people who won't do even easier things that will make their code better to do something that requires this much effort and change.

    You can't just say, "get rid of them and hire some real programmers," either. That's a cop out, and it isn't your call either. We live in a world where our jobs are getting outsourced to people because of cost, not quality. Sad but true.

  • I can only congratulate all the people that write code so good that they don't need testing. And even bigger props to all of you who can maintain and change your code without running into trouble. Since I am not that perfect I have to write tests that must pass before deployment so I can be certain my core business logic works.

    After a little practice everyone can write tests that are a bit more useful then Expect(1+1, EqualTo(2), "The universe is about to explode!"); :)

  • I think there is a disconnect somewhere: Lots of people are teaching but not many people are actually learning.


  • When i write unit test, the application doesn't have new screens.
    My boss does not understand and thinks he pays me for nothing.
    Yes, i could change job... but i won't do it just because of unit test.

  • I'm a developer that fully appreciate the gains of TDD, however I think that there's no benefit in saying that there are no reasons what so ever to NOT doing TDD. There are a couple of drawbacks of TDD. To me the most obvious one is kind of a paradox. TDD promises that your code will be easier to maintain, what you forget to mention is that you're gonna have a larger code base to maintain since you now have all the test code additional to the production code.

    Let's not give people false hopes and a reason to be dissapointed, but let's say that TDD is not all roses and chocolate but it's still a better alternative than having no tests.

  • We're actually using unit tests, and for some of us it's been great. Other people within the team haven't really discovered the pro's. The project is fairly big (a bit over 20 developers and has been active for 1,5 years now). We're using NUNit / NHibernate (great approach to avoid relying on databases, using repositories).

    I see two areas were we're having some minor problems:
    1. The test code isn't treated with as good care as the "production" code. People tend to be a bit sloppy when writing test code.
    2. The unit tests tend to evolve into integration tests making the tests running at check-in slow.

    Both these areas are connected to developers "cheating". What I mean is that some of us write code first and then try to test the code. If you write the test first you usually have an expected result or state change you can assert on. But fairly often if you write code before the test you end up with a method "void DoMyWork(x,y,z);".

    Anyway, every day I appreciate the unit tests more and more. I can make quite risky refactorings in the code base and (hopefully) catch the broken scenarios without starting the system! TDD is one of my favourite tools in the toolbox.

  • Fredrik, I'm developing using the mvp pattern in silverlight, which lends itself well to the silverlight unit testing framework. however, again the issue i have is how dynamic our data is. for instance, lets say i'm writing an app that lists products that are available for you to buy. today there might be three products, tomorrow there might be 7 products, another day you may not have any products available to you. how would i possibly test this to make sure everything is working? when the potential product list could be hundreds? I'd really like for someone to help me figure this out because i really want to start writing test code, but my co-workers give me a hard time because they say our data is too dynamic and it would never work. thanks!

  • When you are talking about brand new projects, or at least projects that aren't that old, unit testing makes a lot of sense and is doable.
    But once you get into very large systems (say, 10 years old), with literally dozens of projects inside tens of solutions and millions of lines of code, all of them very coupled to database (i.e., pretty much every method in the business layer makes a few trips to the db), unit testing becomes very hard. It gets even harder when you also see that most methods cross assembly boundaries all the time, which often times mean hitting some very legacy code in Java or VB6...it is just not that simple.

    All you can do is integration tests, and even then you have to mock so much stuff that it becomes very frustrating, not to mention slow. Adopting a red-green programming style becomes impossible.

    I wish the real world was a big, single northwind sample.

  • By the way, if 95% of developers don't write unit tests, the question probably should be "Why almost no one write unit tests". Putting forth the right question is half the way to get the right answer.

Comments have been disabled for this content.