I am working to integrate unit testing into the development process on the team I work on and there are some skeptics. What are some good ways to convince the skeptical developers on the team of the value of Unit Testing? In my specific case we would be adding Unit Tests as we add functionality or fixed bugs. Unfortunately our code base does not lend itself to easy testing.

+16  A: 

One great thing about unit tests is that they serve as documentation for how your code is meant to behave. Good tests are kind of like a reference implementation, and teammates can look at them to see how to integrate their code with yours.

+1  A: 

The whole point of unit testing is to make testing easy. It's automated. "make test" and you're done. If one of the problems you face is difficult to test code, that's the best reason of all to use unit testing.

+66  A: 

Best way to convince... find a bug, write a unit test for it, fix the bug.

That particular bug is unlikely to ever appear again, and you can prove it with your test.

If you do this enough, others will catch on quickly.

Ed Guiness
This only works if your code is built in such a way that facilitates unit testing (or you use TypeMock). Otherwise you'll spend eons building the test.Most code without unit tests is built with hard dependencies (i.e.'s new's all over the place) or static methods. This makes it almost impossible to just throw a quick unit test in place.
That sounds more like justification for writing a provable bug report, not for unit testing or TDD.
Rei Miyasaka
@Rei - The provable bug report is great, but you're only going to reproduce the bug ONCE. 2 years later, your unit test is still going to be checking the code, long after the bug report has been closed and forgotten.
Orion Edwards
It saves the fix bug 1...test...good. Users find bug 2...fix...test...good. Users find bug 1 again. Lather, rinse, repeat. This happens because your fix for one bug, causes the other, and vice-versa.
@Orion Yeah, but it's only that one instance of that bug on that piece of code... you're unlikely to repeat that same mistake on that same piece of code, even though you're likely to repeat the same mistake on other pieces of code. Maybe if you have several people maintaining the project, yeah, but if that's a concern, it would seem to be nearly just as effective to leave a comment there warning future programmers of the potential problem.
Rei Miyasaka
@Rei Miyasaka: "Maybe if you have several people maintaining the project" - I'd say almost all non-trivial projects do. As to "just leave a comment": The problem is that there may (i.e. *will*) be interactions with other code which might cause the bug to resurface. That's why you actually have to test for it.
Note, however, that tests to prevent regressions are usually integrations tests, and not unit tests (because in my experience most bugs are not in one part of the code only, but arise from the combination of several pieces of code, so you can only reproduce them by combining all these pieces).
@Rei: I agree that *you* are unlikely to repeat the same mistake on the same piece of code, but some other developer may. Also, quite often bugs are not directly in the code, but in how it handles invalid input. Unit tests can check a) that you do in fact handle it, and b) defining HOW the invalid data should be handled. A classic example I see when code reviewing things is stuff like "this code will crash when given an empty array" - but then you have to ask - if it handles an empty array, HOW should it handle it? Unit tests serve as excellent proof and documentation for things like this
Orion Edwards
@sleske Yeah, that's the thing, I wouldn't even call it the same bug if interaction with other code causes new issues. That's a different bug in the same piece of code. If it were the same bug, a unit test would catch it -- which, like you say, it usually wouldn't. Sometimes you might get another bug which results in an error in the same value, in which case a unit test would catch it, but that's really just a coincidence.
Rei Miyasaka
@Orion Ah the documentation factor -- I agree, it serves as documentation. But at the same time, documentation serves as documentation, and you're going to need that either way. Also, when I write a function that's public in any way, I write the input validation first. It's not as if I'm less likely to forget to write a unit test than I am to forget to write documentation or validation. Yeah, documentation can be ignored, but not too often so if you do even one pass of code review -- and that's definitely time better spent.
Rei Miyasaka

Who are you trying to convince? Engineers or manager? If you are trying to convince your engineer co-workers I think your best bet is to appeal to their desire to make a high quality piece of software. There are numerous studies that show it finds bugs, and if they care about doing a good job, that should be enough for them.

If you are trying to convince management, you will most likely have to do some kind of cost/benefit reasoning saying that the cost of the defects that will be undetected is greater than the cost of writing the tests. Be sure to include intagable costs too, such as loss of customer confidence, etc.

Craig H
+5  A: 

A major part of test-driven development that is often glossed over is the writing of testable code. It seems like some kind of a compromise at first, but you'll discover that testable code is also ultimately modular, maintainable and readable. If you still need help convincing people this is a nice simple presentation about the advantages of unit testing.

Tom Martin
+2  A: 

If you are using NUnit one simple but effective demo is to run NUnit's own test suite(s) in front of them. Seeing a real test suite giving a codebase a workout is worth a thousand words...

Garth Gilmour

When you manually test software, you normally have a small set of tests/actions that you use. Eventually you'll automatically morph your input data or actions so that you navigate yourself around known issues. Unit tests should be there to remind you that things do not work correctly.

I recommend writing tests before code, adding new tests/data to evolve the functionality of the main code!

Ray Hayes

As a physics student i am very driven to actually prove that my code works as it is supposed to. You could either prove this logically, which increases in difficulty drastically as implementation gets more complex, or you can make an (as close as possible) empirical proof of function through good testing.

If you don't provide logical proof of function, you have to test. The only alternative is to say "I think the code works...."

+2  A: 

If your existing code base doesn't lend itself to unit testing, and it's already in production, you might create more problems than you solve by trying to refactor all of your code so that it is unit-testable.

You may be better off putting efforts towards improving your integration testing instead. There's lots of code out there that's just simpler to write without a unit test, and if a QA can validate the functionality against a requirements document, then you're done. Ship it.

The classic example of this in my mind is a SqlDataReader embedded in an ASPX page linked to a GridView. The code is all in the ASPX file. The SQL is in a stored procedure. What do you unit test? If the page does what it's supposed to do, should you really redesign it into several layers so you have something to automate?

Eric Z Beard
+7  A: 

One of the best things about unit testing is that your code will become easier to test as you do it. Preexisting code created without tests is always a challenge because since they weren't meant to be unit-tested, it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class - like an e-mail sending service reference - and so on. But don't let this bring you down! You'll see that your overall code design will become better as you start to write unit-tests, and the more you test, the more confident you'll become on making even more changes to it without fear of breaking you application or introducing bugs.

There are several reasons to unit-test your code, but as time progresses, you'll find out that the time you save on testing is one of the best reasons to do it. In a system I've just delivered, I insisted on doing automated unit-testing in spite of the claims that I'd spend way more time doing the tests than I would by testing the system manually. With all my unit tests done, I run more than 400 test cases in less than 10 minutes, and every time I had to do a small change in the code, all it took me to be sure the code was still working without bugs was ten minutes. Can you imagine the time one would spend to run those 400+ test cases by hand?

When it comes to automated testing - be it unit testing or acceptance testing - everyone thinks it's a wasted effort to code what you can do manually, and sometimes it's true - if you plan to run your tests only once. The best part of automated testing is that you can run them several times without effort, and after the second or third run, the time and effort you've wasted is already paid for.

One last piece of advice would be to not only unit test your code, but start doing test first (see TDD and BDD for more)

Alexandre Brasil
+6  A: 

Unit tests are also especially useful when it comes to refactoring or re-writing a piece a code. If you have good unit tests coverage, you can refactor with confidence. Without unit tests, it is often hard to ensure the you didn't break anything.

+2  A: 

Unit testing helps a lot in projects that are larger than any one developer can hold in their head. They allow you to run the unit test suite before checkin and discover if you broke something. This cuts down a lot on instances of having to sit and twiddle your thumbs while waiting for someone else to fix a bug they checked in, or going to the hassle of reverting their change so you can get some work done. It's also immensely valuable in refactoring, so you can be sure that the refactored code passes all the tests that the original code did.

+3  A: 

Unit Testing is definitely worth the effort. Unfortunately you've chosen a difficult (but unfortunately common) scenario into which to implement it.

The best benefit from unit testing you'll get is when using it from the ground up - on a few, select, small projects I've been fortunate enough to write my unit tests before implementing my classes (the interface was already complete at this point). With proper unit tests, you will find and fix bugs in your classes while they're still in their infancy and not anywhere near the complex system that they'll undoubtedly become integrated in in the future.

If your software is solidly object oriented, you should be able to add unit testing at the class level without too much effort. If you aren't that fortunate, you should still try to incorporate unit testing wherever you can. Make sure when you add new functionality the new pieces are well defined with clear interfaces and you'll find unit testing makes your life much easier.

+10  A: 

I think it is. I recommend this article on the subject.

Top 12 Reasons to Write Unit Tests

Alejandro Bologna
+221  A: 

Every day in our office there is an exchange which goes something like this:

"Man, I just love unit tests, I've just been able to make a bunch of changes to the way something works, and then was able to confirm I hadn't broken anything by running the test over it again..."

The details change daily, but the sentiment doesn't. Unit tests and TDD have so many hidden and personal benefits as well as the obvious ones that you just can't really explain to somebody until they're doing it themselves.

But, ignoring that, here's my attempt!

  1. Unit Tests allow you to make big changes to code quickly. You know it works now because you've run the tests, when you make the changes you need to make, you need to get the tests working again. This saves hours.

  2. TDD helps you to realise when to stop coding. Your tests give you confidence that you've done enough for now and can stop tweaking and move on to the next thing.

  3. The tests and the code work together to achieve better code. Your code could be bad / buggy. Your TEST could be bad / buggy. In TDD you are banking on the chances of BOTH being bad / buggy being low. Often it's the test that needs fixing but that's still a good outcome.

  4. TDD helps with coding constipation. When faced with a large and daunting piece of work ahead writing the tests will get you moving quickly.

  5. Unit Tests help you really understand the design of the code you are working on. Instead of writing code to do something, you are starting by outlining all the conditions you are subjecting the code to and what outputs you'd expect from that.

  6. Unit Tests give you instant visual feedback, we all like the feeling of all those green lights when we've done. It's very satisfying. It's also much easier to pick up where you left off after an interruption because you can see where you got to - that next red light that needs fixing.

  7. Contrary to popular belief unit testing does not mean writing twice as much code, or coding slower. It's faster and more robust than coding without tests once you've got the hang of it. Test code itself is usually relatively trivial and doesn't add a big overhead to what you're doing. This is one you'll only believe when you're doing it :)

  8. I think it was Fowler who said: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all". I interprate this as giving me permission to write tests where I think they'll be most useful even if the rest of my code coverage is woefully incomplete.

  9. Good unit tests can help document and define what something is supposed to do

  10. Unit tests help with code re-use. Migrate both your code AND your tests to your new project. Tweak the code till the tests run again.

This presentation is an excellent introduction to the subject. (this version requires Firefox)

A lot of work I'm involved with doesn't Unit Test well (web application user interactions etc.), but even so we're all test infected in this shop, and happiest when we've got our tests tied down. I can't recommend the approach highly enough.

+1 I've only recently started unit testing, but I can relate to nearly all your points. Well said!
Is the presentation you link a .xul?
aye - sorry it is. I don't know if it's changed or if I never noticed before. Requires Firefox. I updated the answer to reflect this.
Thank you, agree with every word!Just a note, you're saying you find it difficult to test user interactions with web applications. I took a look at your profile and it looks like you're a PHP guy. Us testing fanatics in the Ruby world have built a lot of tools to simplify the process of testing web apps. I've built a tool called [Capybara](http://github.com/jnicklas/capybara) which interacts with webapps. I know of a number of people using this to test PHP apps. It's very nicely used together with [cucumber](http://cukes.info/). Check it out!
3rd point: Not true. It is enough for the unit test to be buggy to cause trouble.
Tamás Szelei
+1: As recently as last year, I was a skeptic; but having brought an ASP.NET MVC application from start to finish with automated unit tests, I'm a believer. A big believer. // Thanks for sharing your experience. Mine is similar if not identical.
Jim G.
A lot of your reasons for "Unit Testing" seemed more in support of TDD in general, and less focused on the *specific* advantages of Unit Testing opposed to other types of TDD. I for one am a huge fan of TDD, but Unit Testing is too over the top. I'd much prefer to have a fair amount of integration tests than a million Unit Tests.
-1 Code doesn't work until it's used; unit test only delay the real thing (SOMEBODY's gotta downvote this nonsense lol)
+1  A: 

One of the benefits of unit testing is predictability.

Before unit testing I could have predicted to a great degree of accuracy how long it would take to code something, but not how how much time I would need to debug it.

These days, since I can plan what tests I am going to write, I know how long coding is going to take, and at the end of coding, the system is already debugged! This brings predictability to the development process, which remove a lot of the pressure but still retains all the joy!!.

+12  A: 

Unit-testing is well worth the initial investment. Since starting to use unit-testing a couple of years ago, I've found some real benefits:

  • regression testing removes the fear of making changes to code (there's nothing like the warm glow of seeing code work or explode every time a change is made)
  • executable code examples for other team members (and yourself in six months time..)
  • merciless refactoring - this is incredibly rewarding, try it!

Code snippets can be a great help in reducing the overhead of creating tests. It isn't difficult to create snippets that enable the creation of a class outline and an associated unit-test fixture in seconds.

Jonathan Webb
+7  A: 

In short - yes. They are worth every ounce of effort... to a point. Tests are, at the end of the day, still code, and much like typical code growth, your tests will eventually need to be refactored in order to be maintainable and sustainable. There's a tonne of GOTCHAS! when it comes to unit testing, but man oh man oh man, nothing, and I mean NOTHING empowers a developer to make changes more confidently than a rich set of unit tests.

I'm working on a project right now.... it's somewhat TDD, and we have the majority of our business rules encapuslated as tests... we have about 500 or so unit tests right now. This past iteration I had to revamp our datasource and how our desktop application interfaces with that datasource. Took me a couple days, the whole time I just kept running unit tests to see what I broke and fixed it. Make a change; Build and run your tests; fix what you broke. Wash, Rinse, Repeat as necessary. What would have traditionally taken days of QA and boat loads of stress was instead a short and enjoyable experience.

Prep up front, a little bit of extra effort, and it pays 10-fold later on when you have to start dicking around with core features/functionality.

I bought this book - it's a Bible of xUnit Testing knowledge - tis probably one of the most referenced books on my shelf, and I consult it daily: link text

+1: *but man oh man oh man, nothing, and I mean NOTHING empowers a developer to make changes more confidently than a rich set of unit tests.* - So true. I wish I figured this out sooner.
Jim G.
+5  A: 

You should test as little as possible!

meaning, you should write just enough unit tests to reveal intent. This often gets glossed over. Unit testing costs you. If you make changes and you have to change tests you will be less agile. Keep unit tests short and sweet. Then they have a lot of value.

Too often I see lots of tests that will never break, are big and clumsy and don't offer a lot of value, they just end up slowing you down.

Keith Nicholas
+2  A: 

With unit test suite one can make changes to code while leaving rest of the features intact. Its a great advantage. Do you use Unit test sutie and regression test suite when ever you finish coding new feature.

+2  A: 

Yes - Unit Testing is definitely worth the effort but you should know it's not a silver bullet. Unit Testing is work and you will have to work to keep the test updated and relevant as code changes but the value offered is worth the effort you have to put in. The ability to refactor with impunity is a huge benefit as you can always validate functionality by running your tests after any change code. The trick is to not get too hung up on exactly the unit-of-work you're testing or how you are scaffolding test requirements and when a unit-test is really a functional test, etc. People will argue about this stuff for hours on end and the reality is that any testing you do as your write code is better than not doing it. The other axiom is about quality and not quantity - I have seen code-bases with 1000's of test that are essentially meaningless as the rest don't really test anything useful or anything domain specific like business rules, etc of the particular domain. I've also seen codebases with 30% code coverage but the tests were relevant, meaningful and really awesome as they tested the core functionality of the code it was written for and expressed how the code should be used.

One of my favorite tricks when exploring new frameworks or codebases is to write unit-tests for 'it' to discover how things work. It's a great way to learn more about something new instead of reading a dry doc :)

Vinny Carpenter
+3  A: 

I recently went through the exact same experience in my workplace and found most of them knew the theoretical benefits but had to be sold on the benefits to them specifically, so here were the points I used (successfully):

  • They save time when performing negative testing, where you handle unexpected inputs (null pointers, out of bounds values, etc), as you can do all these in a single process.
  • They provide immediate feedback at compile time regarding the standard of the changes.
  • They are useful for testing internal data representations that may not be exposed during normal runtime.

and the big one...

  • You might not need unit testing, but when someone else comes in and modifies the code without a full understanding it can catch a lot of the silly mistakes they might make.
+1: *•You might not need unit testing, but when someone else comes in and modifies the code without a full understanding it can catch a lot of the silly mistakes they might make.* - Yup. And given the amount of turnover in the software industry, this is a huge benefit.
Jim G.
+3  A: 

When you said, "our code base does not lend itself to easy testing" is the first sign of a code smell. Writing Unit Tests means you typically write code differently in order to make the code more testable. This is a good thing in my opinion as what I've seen over the years in writing code that I had to write tests for, it forced me to put forth a better design.

Keith Elder
+9  A: 

For years, I've tried to convince people that they needed to write unit test for their code. Whether they wrote the tests first (as in TDD) or after they coded the functionality, I always tried to explain them all the benefits of having unit tests for code. Hardly anyone disagreed with me. You cannot disagree with something that is obvious, and any smart person will see the benefits of unit test and TDD.

The problem with unit testing is that it requires a behavioral change, and it is very hard to change people's behavior. With words, you will get a lot of people to agree with you, but you won't see many changes in the way they do things.

You have to convince people by doing. Your personal success will atract more people than all the arguments you may have. If they see you are not just talking about unit test or TDD, but you are doing what you preach, and you are successful, people will try to imitate you.

You should also take on a lead role because no one writes unit test right the first time, so you may need to coach them on how to do it, show them the way, and the tools available to them. Help them while they write their first tests, review the tests they write on their own, and show them the tricks, idioms and patterns you've learned through your own experiences. After a while, they will start seeing the benefits on their own, and they will change their behavior to incorporate unit tests or TDD into their toolbox.

Changes won't happen over night, but with a little of patience, you may achieve your goal.

+134  A: 

Unit testing is a lot like going to the gym. You know it is good for you, all the arguments make sense, so you start working out. There's an initial rush, which is great, but after a few days you start to wonder if it is worth the trouble. You're taking an hour out of your day to change your clothes and run on a hamster wheel and you're not sure you're really gaining anything other than sore legs and arms.

Then, after maybe one or two weeks, just as the soreness is going away, a Big Deadline begins approaching. You need to spend every waking hour trying to get "useful" work done, so you cut out extraneous stuff, like going to the gym. You fall out of the habit, and by the time Big Deadline is over, you're back to square one. If you manage to make it back to the gym at all, you feel just as sore as you were the first time you went.

You do some reading, to see if you're doing something wrong. You begin feel a little bit of irrational spite toward all the fit, happy people extolling the virtues of exercise. You realize that you don't have a lot in common. They don't have to drive 15 minutes out of the way to go to the gym; there is one in their building. They don't have to argue with anybody about the benefits of exercise; it is just something everybody does and accepts as important. When a Big Deadline approaches, they aren't told that exercise is unnecessary any more than your boss would ask you to stop eating.

So, to answer your question, Unit Testing is usually worth the effort, but the amount of effort required isn't going to be the same for everybody. Unit Testing may require an enormous amount of effort if you are dealing with spaghetti code base in a company that doesn't actually value code quality. (A lot of managers will sing Unit Testing's praises, but that doesn't mean they will stick up for it when it matters.)

If you are trying to introduce Unit Testing into your work and are not seeing all the sunshine and rainbows that you have been led to expect, don't blame yourself. You might need to find a new job to really make Unit Testing work for you.

awesome anecdote!
Sander Versluys
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
Christopher Parker
wouldn't you want to join a company where unit testing isn't needed? For instance, if you have a good diet, you probably don't need to loose weight by running on the hamster wheel.
That's a spectacularly good answer, fits my experience very well.
Crap, I already unit tested but now you make me feel like I need to go to the gym.
I don't like either. I fail as a geek and as a human.
@user8863: Except its not just a good diet, but good exercise that you need as well. It's like reading all the good software engineering books but never applying the knowledge. In reality, we know things are different but its always good to strive for the best
+1: *A lot of managers will sing Unit Testing's praises, but that doesn't mean they will stick up for it when it matters... You might need to find a new job to really make Unit Testing work for you.* - Great points. Very true.
Jim G.
+3  A: 

Occasionally either myself or one of my co-workers will spend a couple of hours getting to the bottom of slightly obscure bug and once the cause of the bug is found 90% of the time that code isn't unit tested. The unit test doesn't exist because the dev is cutting corners to save time, but then looses this and more debugging.

Taking the small amount of time to write a unit test can save hours of future debugging.

Jon Cahill
+1: *Taking the small amount of time to write a unit test can save hours of future debugging.* - Yup!
Jim G.
+29  A: 

thetalkingwalnut asks:

What are some good ways to convince the skeptical developers on the team of the value of Unit Testing?

Everyone here is going to pile on lots of reasons out of the blue why unit testing is good. However, I find that often the best way to convince someone of something is to listen to their argument and address it point by point. If you listen and help them verbalize their concerns, you can address each one and perhaps covert them to your point of view (or at the very least, leave them without a leg to stand on). Who knows? Perhaps they will convince you why unit tests aren't appropriate for your situation. Not likely, but possible. Perhaps if you post their arguments against unit tests, we can help identify the counterarguments.

Its important to listen and understand both sides of the argument. If you try to adopt unit tests too zealously without regard to people's concerns, you'll end up with a religious war (and probably really worthless unit tests). If you adopt it slowly and start by apply it where you will see the most benefit for the least cost, you might be able to demonstrate value of unit tests and have a better chance of convincing people. I realize this isn't as easy as it sounds - it usually requires some time and careful metrics to craft a convincing argument.

Unit tests are a tool, like any other, and should be applied in a way such that the benefits (catching bugs) outweigh the costs (the effort writing them). Don't use them if/where they don't make sense and remember that they are only part of your arsenal of tools (e.g. inspections, assertions, code analyzers, formal methods, etc). What I tell my developers is this:

  1. They can skip writing a test for a method if they have a good argument why it isn't necessary (e.g. too simple to be worth it or too difficult to be worth it) and how the method will be otherwise verified (e.g. inspection, assertions, formal methods, interactive/integration tests). They need to consider that some verifications like inspections and formal proofs are done at a point in time and then need to be repeated every time the production code changes, whereas unit tests and assertions can be used as regression tests (written once and executed repeatedly thereafter). Sometimes I agree with them, but more often I will debate about whether a method is really too simple or too difficult to unit test.

  2. If a developer argues that a method seems too simple to fail, isn't worth taking the 60 seconds necessary to write up a simple 5-line unit test for it? These 5 lines of code will run every night (you do nightly builds, right?) for the next year or more and will be worth the effort if even just once it happens to catch a problem that may have taken 15 minutes or longer to identify and debug. Besides, writing the easy unit tests drives up the count of unit tests, which makes the developer look good.

  3. On the other hand, if a developer argues that a method seems too difficult to unit test (not worth the significant effort required), perhaps that is a good indication that the method needs to be divided up or refactored to test the easy parts. Usually, these are methods that rely on unusual resources like singletons, the current time, or external resources like a database result set. These methods usually need to be refactored into a method that gets the resource (e.g. calls getTime()) and a method that takes the resource as a argument (e.g. takes the timestamp as a parameter). I let them skip testing the method that retrieves the resource and they instead write a unit test for the method that now takes the resource as a argument. Usually, this makes writing the unit test much simpler and therefore worthwhile to write.

  4. The developer needs to draw a "line in the sand" in how comprehensive their unit tests should be. Later in development, whenever we find a bug, they should determine if more comprehensive unit tests would have caught the problem. If so and if such bugs crop up repeatedly, they need to move the "line" toward writing more comprehensive unit tests in the future (starting with adding or expanding the unit test for the current bug). They need to find the right balance.

Its important to realize the unit tests are not a silver bullet and there is such a thing as too much unit testing. At my workplace, whenever we do a lessons learned, I inevitable hear "we need to write more unit tests". Management nods in agreement because its been banged into their heads that "unit tests" == "good".

However, we need to understand the impact of "more unit tests". A developer can only write ~N lines of code a week and you need to figure out what percentage of that code should be unit test code vs production code. A lax workplace might have 10% of the code as unit tests and 90% of the code as production code, resulting in product with a lot of (albeit very buggy) features (think MS Word). On the other hand, a strict shop with 90% unit tests and 10% production code will have a rock solid product with very few features (think "vi"). You may never hear reports about the latter product crashing, but that likely has as much to do with the product not selling very well as much as it has to do with the quality of the code.

Worse yet, perhaps the only certainty in software development is that "change is inevitable". Assume the strict shop (90% unit tests/10% production code) creates a product that has exactly 2 features (assuming 5% of production code == 1 feature). If the customer comes along and changes 1 of the features, then that change trashes 50% of the code (45% of unit tests and 5% of the production code). The lax shop (10% unit tests/90% production code) has a product with 18 features, none of which work very well. Their customer completely revamps the requirements for 4 of their features. Even though the change is 4 times as large, only half as much of the code base gets trashed (~25% = ~4.4% unit tests + 20% of production code).

My point is that you have to communicate that you understand that balance between too little and too much unit testing - essentially that you've thought through both sides of the issue. If you can convince your peers and/or your management of that, you gain credibility and perhaps have a better chance of winning them over.

Bert F
If Vi has very few features, you're not using it. ;)
Stefan Mai
+20 for Stefan, if I could :)
Robert Grant
Show me mail merge with Vi
Testivus on Test Coverage - http://googletesting.blogspot.com/2010/07/code-coverage-goal-80-and-no-less.html
Bert F
Oh! This primitive *six* editor! It even does not have an option to close it!

Make the first things you test not related to unit testing. I work mostly in Perl, so these are Perl-specific examples, but you can adapt.

  • Does every module load and compile correctly? In Perl, this is a matter of creating a Foo.t for each Foo.pm in the code base that does:

    use_ok( 'Foo' );

  • Is all the POD (Plain Ol' Documentation) formatted properly? Use Test::Pod to validate the validity of the formatting of all the POD in all the files.

You may not think these are big things, and they're not, but I can guarantee you will catch some slop. When these tests run once an hour, and it catches someone's premature commit, you'll have people say "Hey, that's pretty cool."

Andy Lester
+5  A: 

I didn't see this in any of the other answers, but one thing I noticed is that I could debug so much faster. You don't need to drill down through your app with just the right sequence of steps to get to the code your fixing, only to find you've made a boolean error and need to do it all again. With a unit test, you can just step directly into the code you're debugging.

John MacIntyre

Unit testing works for QA guys or your managers, not for you; so it's definitely not worth it.

You should focus on writing correct code (whatever it means), not test cases. Let other guys worry about those.

-1: Not true. As a developer, you should always worry about breaking existing functionality. When done right, automated unit tests can make you feel more confident that your new code doesn't break existing features.
Jim G.
Meaningless statement. How you intend to determine whether or not your code is 'correct' without testing it?
Tom W
Go get'em Tom W! Unit testing is the answer to your "whatever it means". This comment is a big, huge, gigantic fail.
Ryan Cromwell

Unit testing help you to release software with fewer bugs while reducing overall development costs. You can click the link to read more about the benefits of unit testing

+8  A: 

I have toyed with unit testing a number of times, and I am still to be convinced that it is worth the effort given my situation.

I develop websites, where much of the logic involves creating, retrieving or updating data in the database. When I have tried to "mock" the database for unit testing purposes, it has got very messy and seemed a bit pointless.

When I have written unit tests around business logic, it has never really helped me in the long run. Because I largely work on projects alone, I tend to know intuitively which areas of code may be affected by something I am working on, and I test these areas manually. I want to deliver a solution to my client as quickly as possible, and unit testing often seems a waste of time. I list manual tests and walk through them myself, ticking them off as I go.

I can see that it may be beneficial when a team of developers are working on a project and updating each other's code, but even then I think that if the developers are of a high quality, good communication and well-written code should often be enough.

+2  A: 

I'm working as a maintenance-engineer of a poorly documented, awful and big code base. I wish the people who wrote the code had written the unit tests for it.
Each time I make a change and update the production code I'm scared that I might introduce a bug for not having considered some condition.
If they wrote the test making changes to the code base would be easier and faster.(at the same time the code base would be in a better state)..

I think unit tests prove a lot useful when writing api or frameworks that have to last for many years and to be used/modified/evolved by people other than the original coders.

+2  A: 

I discovered TDD a couple of years ago, and have since written all my pet projects using it. I have estimated that it takes roughly the same time to TDD a project as it takes to cowboy it together, but I have such increased confidence in the end product that I can't help a feeling of accomplishment.

I also feel that it improves my design style (much more interface-oriented in case I need to mock things together) and, as the green post at the top writes, it helps with "coding constipation": when you don't know what to write next, or you have a daunting task in front of you, you can write small.

Finally, I find that by far the most useful application of TDD is in the debugging, if only because you've already developed an interrogatory framework with which you can prod the project into producing the bug in a repeatable fashion.

Kaz Dragon
+1  A: 

[I have a point to make that I cant see above]

"Everyone unit tests, they don't necessarily realise it - FACT"

Think about it, you write a function to maybe parse a string and remove new line characters. As a newbie developer you either run a few cases through it from the command line by implementing it in Main() or you whack together a visual front end with a button, tie up your function to a couple of text boxes and a button and see what happens.

That is unit testing - basic and badly put together but you test the piece of code for a few cases.

You write something more complex. It throws errors when you throw a few cases through (unit testing) and you debug into the code and trace though. You look at values as you go through and decide if they are right or wrong. This is unit testing to some degree.

Unit testing here is really taking that behaviour, formalising it into a structured pattern and saving it so that you can easily re-run those tests. If you write a "proper" unit test case rather than manually testing, it takes the same amount of time, or maybe less as you get experienced, and you have it available to repeat again and again

Chris Gill

Unit test is not very useless, but it dose not improve the overall quality, since your program will always have certain part which is not unit testable.

Unit test will also make the programmers feel that they do not need to write quality code, because there is a unit test to safe-guard them.

spelling and grammer - you should have unit tested your response.
Yours likewise.
Tom W
If your program has parts that aren't testable, that's already a code smell you should fix. If your unit tests define behavior as well as performance, then the code underneath should also be adequate. There's also additional things like peer reviews that help with poor code.
+2  A: 

I do not know. A lot of places do not do unit test, but the quality of the code is good. Microsoft does unit test, but Bill Gates gave a blue screen at his presentation.

Note that was almost 15 years ago, when unit testing wasn't as popular as it is today.

Testing is more like dieting than exercise.. coding is exercise.. testing is preventative measure.. a sage coder once said.. given enough eyeballs, all bugs are shallow. Code a lot and you inherently end up testing coeval. Cheers.

Peter Herz
This post doesn't make any sense. Coherent prose is essential when replying to topics, particularly ones that are subjective.
Tom W

Just today, I had to change a class for which a unit test has been written previously.
The test itself was well written and included test scenarios that I hadn't even thought about.
Luckily all of the tests passed, and my change was quickly verified and put into the test environment with confidence.


This is very .Net-centric, but has anybody tried Pex?

I was extremely sceptical until I tried it - and wow, what a performance. Before I thought "I'm not going to be convinced by this concept until I understand what it's actually doing to benefit me". It took a single run for me to change my mind and say "I don't care how you know there's the risk of a fatal exception there, but there is and now I know I have to deal with it"

Perhaps the only downside to this behaviour is that it will flag up everything and give you a six month backlog. But, if you had code debt, you always had code debt, you just didn't know it. Telling a PM there are a potential two hundred thousand points of failure when before you were aware of a few dozen is a nasty prospect, which means it is vital that the concept is explained first.

Tom W
+1  A: 

The one thing to keep in mind about unit testing is that it's a comfort for the developer.

In contrast, functional tests are for the users: whenever you add a functional test, you are testing something that the user will see. When you add a unit test, you are just making your life easier as a developer. It's a little bit of a luxury in that respect.

Keep this dichotomy in mind when you have to make a choice between writing a unit or a functional test.

-- Cédric

Cedric Beust
+1  A: 

I wrote a very large blog post about the topic. I've found that unit testing alone isn't worth the work and usually gets cut when deadlines get closer.

Instead of talking about unit testing from the "test-after" verification point of view, we should look at the true value found when you set out to write a spec/test/idea before the implementation.

This simple idea has changed the way I write software and I wouldn't go back to the "old" way.


Toran Billups
+1 - and I must say it's mind-boggling how many trolls that blog entry attracted (prior to you posting here, if I'm not mistaken).
Jeff Sternal
haha agreed :) </ reddit front-page does that it seems>
Toran Billups