By Ross Fuhrman

2008-09-15 21:44:00 8 Comments

I am working to integrate unit testing into the development process on the team I work on and there are some sceptics. What are some good ways to convince the sceptical 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.


@Bert F 2008-09-16 07:02:52

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

It's important to listen to 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 applying it where you will see the most benefit for the least cost, you might be able to demonstrate the 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 such a way 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.

    • If a developer argues that a method seems too simple to fail, isn't it 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.

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

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

@Stefan Mai 2009-06-26 18:14:22

If Vi has very few features, you're not using it. ;)

@Rob Grant 2010-01-19 17:11:17

+20 for Stefan, if I could :)

@Bert F 2010-07-20 19:39:44

Testivus on Test Coverage -…

@nicodemus13 2013-10-18 00:14:38

A good analysis, though two things I'd say. You seem to assume that changing a feature requires rewriting all the code that it relies on and it's rather an assumption that there's a linear relationship between change and 'amount of code' change. Also, a product with low testing is more likely to have a worse design, hence the 'lots-of-features' product will almost certainly take much longer per feature (as there are almost no tests and an implicitly bad design).

@bgs 2013-10-19 19:23:02

writing test case for simple code block serves as a regression mechanism - only negative I had seen is adding more stack frames...

@reefnet_alex 2008-09-15 22:06:22

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 test-driven development (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 allows 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 interpret 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.

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.

@user2427 2010-03-11 04:08:47

Is the presentation you link a .xul?

@ZunTzu 2014-10-16 12:12:27

The question was about unit testing. TDD is a whole different thing than unit testing.

@Andy Lester 2008-09-20 04:47:09

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

@Cedric Beust 2010-10-01 00:10:44

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.

@Toran Billups 2010-10-01 15:28:04

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.

How test first development changed my life

@Jeff Sternal 2010-10-01 15:56:04

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

@Toran Billups 2010-10-02 21:11:49

haha agreed :) </ reddit front-page does that it seems>

@Liorp 2010-11-17 17:09:46

From my experience, unit tests and integration tests are a "MUST HAVE" in complex software environments.

In order to convince the developers in your team to write unit tests you may want to consider integrating unit test regression analysis in your development environment (for example, in your daily build process).

Once developers know that if a unit test fails they don't have to spend so much time on debugging it to find the problem, they would be more encouraged to write them.

Here's a tool which provides such functionality:

unit test regression analysis tool

@RoiG 2012-01-16 09:19:30

Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? See here

@Samuel Åslund 2011-10-01 08:42:28

One thing no-one has mentioned yet is getting the commitment of all developers to actually run and update any existing automated test. Automated tests that you get back to and find broken because of new development looses a lot of the value and make automated testing really painful. Most of those tests will not be indicating bugs since the developer has tested the code manually, so the time spent updating them is just waste.

Convincing the skeptics to not destroy the work the others are doing on unit-tests is a lot more important for getting value from the testing and might be easier.

Spending hours updating tests that has broken because of new features each time you update from the repository is neither productive nor fun.

@DSblizzard 2011-02-25 12:08:47

I'm agree with the point of view opposite to the majority here: It's OK Not to Write Unit Tests Especially prototype-heavy programming (AI for example) is difficult to combine with unit testing.

@Trystan Spangler 2010-12-20 07:50:47

@George Stocker "Unfortunately our code base does not lend itself to easy testing.". Everyone agrees that there are benefits to unit testing but it sounds like for this code base the costs are high. If the costs are greater than the benefits then why should they be enthusiastic about it? Listen to your coworkers; maybe for them the perceived pain of unit tests is greater than the perceived value of unit tests.

Specifically, try to gain value as soon as possible, and not some feel-goodery "xUnit is green" value, but clean code that users and maintainers value. Maybe you have to mandate unit tests for one iteration and then discuss if it is worth the effort or not. 2009-07-20 15:39:01

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.

@oɔɯǝɹ 2015-01-22 22:32:17

Do you add unit tests for new code or fixes that you make?

@Tom W 2010-09-30 18:27:07

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.

@crowne 2010-09-30 18:21:30

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.

@BigTiger 2010-05-21 00:25:32

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.

@cthulhu 2010-10-19 14:33:03

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

@Cees Timmerman 2012-12-19 09:50:49

And Internet Explorer still fails to save many a webpage.

@Chris Gill 2009-08-19 15:12:26

[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

@Kaz Dragon 2009-07-20 16:02:35

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.

@Ronnie 2009-07-08 11:19:57

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.

@Josh Ribakoff 2013-04-25 04:06:39

I know this is very old but I am compelled to comment. I personally have found success writing tests for my persistence layer. Simply start a transaction before the test & roll it back afterwards. No mocking needed. Sometimes I have one class to pull an array of data, I then pass that array of data to a second class that does "things" to the data. This second class does not touch the database. In this case I group my tests, the ones that test the first class & touch the database are 'functional tests' and run infrequently, the tests for the latter class are unit tests & run frequently.

@Bob Jarvis - Reinstate Monica 2013-10-02 18:20:03

Testing is all about happiness. I've got a 3900-line package (PL/SQL) that handles automated postings to the general ledger system. Now, I personally hate dealing with accountants - they're so picky about little things like fractional pennies and stuff. Buncha anal-retentive arithmetic geeks...I dunno. My unit test package for the accounting package is about 22000 lines, and runs just under 18000 tests. This keeps the Head Honcho in Accounting all happy, and as long as the propeller on his little beanie-counting-cap is spinning happily, I'm happy... :-)

@Steve_0 2009-06-18 10:41:42

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

@Mark 2009-02-10 00:59:53

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.

@Jim G. 2010-09-30 19:20:11

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

@Tom W 2010-09-30 20:28:12

Meaningless statement. How you intend to determine whether or not your code is 'correct' without testing it?

@Ryan Cromwell 2010-10-04 14:56:28

Go get'em Tom W! Unit testing is the answer to your "whatever it means". This comment is a big, huge, gigantic fail.

@Teoman shipahi 2014-04-30 21:41:29

one of the worst SO answer ever.

@John MacIntyre 2009-02-10 00:21:56

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.

@pkaeding 2008-09-15 21:46:25

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.

@dlanod 2008-09-16 00:41:45

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.

@Jim G. 2010-09-30 19:16:51

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

@Jon Cahill 2008-09-16 05:11:35

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.

@Jim G. 2010-09-30 19:15:48

+1: Taking the small amount of time to write a unit test can save hours of future debugging. - Yup!

@benzado 2008-09-16 03:53:18

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.

@Sander Versluys 2010-04-15 14:22:35

awesome anecdote!

@Christopher Parker 2010-08-30 13:45:02

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

@mempko 2010-09-30 14:38:19

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.

@NM. 2010-09-30 14:41:11

That's a spectacularly good answer, fits my experience very well.

@Vince 2010-09-30 17:36:19

Crap, I already unit tested but now you make me feel like I need to go to the gym.

@Greg 2010-09-30 18:29:47

I don't like either. I fail as a geek and as a human.

@user195488 2010-09-30 18:50:17

@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

@Jim G. 2010-09-30 18:54:49

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

@JDPeckham 2011-03-28 02:40:02

idiots with ugly code will fail at unit testing even if they are not too lazy to try it. Pros will unit test and have lovely code, but then be bored of it and move on to another project. The rest of us will unit test a little bit here and there when we really need it and we'll do 'Just Fine".

@Lauri 2012-04-05 11:51:58

I used to work somewhere where we didn't unit-test. In fact people who tried unit-testing there soon went to work somewhere else. Now I'm working where I may and have to unit-test. Loving it a lot more.

@Bob Jarvis - Reinstate Monica 2013-10-02 18:00:44

My boss said I was fat and should stop eating (well, OK, cut way down). I just held up a bottle of barbecue sauce and smiled a smile that would have made the Cheshire Cat proud. Best. Ribs. Ever!

@Apprentice Queue 2013-11-01 00:20:43

Well if you spend too much time at the gym, you might neglect other more important things in life.

@rfcoder89 2013-11-18 11:45:16

@ApprenticeQueue too much of anything is a bad thing

@rkulla 2014-04-16 17:18:41

Code is automated instructions to a computer. Tests are automated code to make sure said code is working. You even need tests for some of your tests depending on what they do. Most people are fine with testing on paper or after doing a simple tutorial. But once they try it on their own project, after it's been written, they realize it's very hard to do right -- especially with things that need Test Doubles. Thus the key is learn good testing engineering and to do it up front before your code is difficult test. Doing it all the time is required for being good at it anyway, just like anything.

@Curro 2008-09-16 01:32:10

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.

@Keith Elder 2008-09-16 00:55:06

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.

@Vinny Carpenter 2008-09-15 23:46:59

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

@Shinwari 2008-09-15 23:37:47

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.

@Keith Nicholas 2008-09-15 23:32:32

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.

@Jonathan Webb 2008-09-15 22:15:30

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.

Related Questions

Sponsored Content

55 Answered Questions

17 Answered Questions

26 Answered Questions

[SOLVED] How should I unit test threaded code?

11 Answered Questions

[SOLVED] Is there hard evidence of the ROI of unit testing?

  • 2008-10-25 20:59:10
  • raven
  • 12930 View
  • 127 Score
  • 11 Answer
  • Tags:   unit-testing tdd

7 Answered Questions

13 Answered Questions

[SOLVED] JavaScript unit test tools for TDD

23 Answered Questions

Sponsored Content