How has unit testing made your life better ?

Question

Ok let me be honest, I haven't more than 10 unit tests in my life probably.

I am embarking on a new project, and being the sole programmer means I should be scared ... very scared.

The idea that I can pseudo guarantee that my software works brings about a sense of joy.

Sure I will miss a ton of cases where I should have tested, but that's where I will learn as time goes on.

Unit testing will help me sleep better at night, which is better for my health.

My code will fail, but at least I will have a better idea when it will.

How has unit testing made your life better (or has it?), despite the rest of your team not jumping on the bandwagon?

Answer 1

By unit testing, I've reduced the number of "stupid-bugs" that get reported during the testing stage. It's also given me a higher level of confidence in my code.

Answer 2

I'm currently in the process of trying to jump on the bandwagon. Work mates are already doing it before they've written a line of functional code. I'm still writing a full program before I've even run it through the main, let alone unit test it :/

I'll get there in the end I'm sure. But at the moment, I am of ill health through spending 90% of my life debugging :(

Answer 3

Can't speak for everyone, but I started writing tests because of a fellow developer that wrote tests that were a big help to me when I was learning the system.

I've also found that tests are a good way to verify assumptions when working with a new code base.

Answer 4

Unit testing is not a silver bullet. But it does have benefits, and it is very satisfying.

I find it means my code gets executed a lot earlier, since before I wrote unit tests, it took a lot of coding before there was enough functionality to try out in the application.

I'm also very grateful for my suite of unit tests when I come to refactor. I rewrote a whole date handling module a while ago, and there's no way I would have had the confidence to do that without regression tests.

Answer 5

Using unit testing in conjunction with TDD provides me with motivation and drive to complete the task at hand. Without the small progress of writing test, fixing test, writing test, fixing test I can become unmotivated.

Answer 6

I must say that I think the improvements in VS 2010, such as Ctrl+Enter (I think that was what it was) that can allow you to quickly stub the interface of a class while writing test (first) is going to make this ALOT easier for me.

Answer 7

As Elie said, unit-testing is a great way to flush out "stupid" or simple bugs very early. For me, it changes the way I think about code; making my code testable makes it less brittle and more flexible (e.g. depenceny injection/inversion of control came quite naturally to me because it's something I did for testing purposes anyway).

The greatest benefit I personally get from a thorough test-suite is the confidence to change complicated code even months after I wrote it without fear of accidentally breaking something.

I'm not yet there, but with some discipline while writing them, unit-tests are a great way to document your code, also.

Answer 8

Unit tests are really helpful when you start debugging as well. If your tests fail, then you know where the bug is almost immediately. If they all run, then you know where the bugs aren't (most of the time).

Another area where unit tests help: migrating software. I'm finding that it's a lot easier to prepare Python code that has unit tests to be migrated to Python 3 than code that doesn't have unit tests.

Sure I will miss a ton of cases where I should have tested, but that's where I will learn as time goes on.

This is where Test Driven Development really shines. You don't have to worry quite as much about having the proper tests because that question will be answered for you beforehand.

Of course, just to make sure we're on the same page, "test driven development" means the process of coding where you write the test, verify that the test fails, and then write the code.

Answer 9

For me, it wasn't just unit tests that changed my life, but Test Driven Development (TDD). I liken it to a religious experience in my blog post (shameless, I know) My Year with TDD.

Getting into testing has been a career changing experience for me. I write less bugs, I write more readable code, I write more cohesive code, I know when something is broken (usually), etc, etc. I owe it all to Test Driven Development.

Try it, you like it :)

Answer 10

I've been a TDD(eveloper) since my 2nd* project at uni (back in 1988). I don't know if the term was even in use then.

The best thing is the ability to change things and very quickly check you haven't broken anything else. Easy regression testing.

They are good documentation of object/method usage as well.

*and that was directly because of how the first project went....

Answer 11

I've done quite a bit of work in java, and a year in Ruby.

In Ruby we used extensive testing (TDD). This was ABSOLUTELY REQUIRED. You can write nearly complete garbage into a Ruby file, and if you don't hit that specific line of code, you'll never know, so your tests need near 100% coverage.

In Java, I've never needed much more than a single, simple success path test--and that can usually be thrown away after the code runs. It's really the static type checking, strong typing and using coding patterns like strong encapsulation and parameter checking that makes this possible. You can actually get very close to proving that a small class can't be broken (is bug free) without tests, and when correctly designed, all classes should be small.

Another point of interest: On the Ruby project, we had a refactor that took us 2 days of real code work (split a prime model class into two classes) and 2 weeks of test repairs.

At some point all those tests have a price, they are still code you have to maintain.

That said, I find TDD fun and a good way to get things started, even in Java, and I also would reiterate that I ALWAYS have some success path testing at the very least (even if it's just a quick main method) in virtually every class I write.

Answer 12

Okay, as nobody else has stepped up to the plate to play devil's advocate, I'll do it.

Automated unit testing can have good benefits for some projects, but can also have many of the following issues:

• It sucks down a ton of engineering resources.
• It can take many man-hours to remove environment and setup issues from the equation.
• It has a low ROI for some project types, especially GUIs.
• It won't catch many errors, because it's impossible to evaluate all execution paths for all but the most trivial programs.
• It doesn't catch integration errors.
• It doesn't catch broader system-level errors such as functions performed across multiple units, or non-functional areas such as performance.
• Test coverage and coverage gates can become an increasingly useless mantra
• It requires a sustainable process for ensuring that test case failures are reviewed and addressed immediately. Otherwise the app will evolve out of sync with the unit test suite.
• It has a significant opportunity cost - there are other activities such as code reviews that have an equally good or even better ROI.
• It can involve a significant culture change.

So developers shouldn't adopt a dogmatic (yes or no) approach towards unit testing, but instead do an ROI calculation for every project.

Answer 13

The far biggest value that unit test have on my project is confidence. With that confidence it's much easier to add new features that weren't planned at the begging and to tear code apart to change something or turn this around.

With test I know I (or anyone else!) haven't broke something that already worked.

Without test you are brave (or stupid) when you make big changes and deploy them in production in the next minute.

Answer 14

Good unit tests that provide sufficient coverage can make you sleep better at night.

If you use assertions, you can find out potential bugs which are missed by the unit tests (sometimes it's not good enough perhaps), and you can sleep even better at night.

Answer 15

Unit test advantages are multiple. To be more specific of how it makes my life better, well, I think that it's increase the confidence in change and give me the possibility to change a lot faster a code later. It increase my life in the long run.

Of course, I can tell that in short time that it's a little bit of more pain because it requires more time, but it's rapidly forgotten when you auto-validate yourself when you do these test.

Answer 16

Now that I foster to test-drive my code, I know when I'm done with a function, a component, or a feature. Therefore I can report progress accurately.

I know it's not bug free code, but it is functional enough to be integrated, built and delivered to QA. I'm confident they'll be able to start testing without being blocked by a segmentation error, or any other silly problem.

I also have an environment ready so that I can quickly write a new test to reproduce any problem that will be reported, and I have a safety net to detect side effects and regressions when I modify or fix the code.

Answer 17

I'm a big fan of unit testing, though my tests don't provide complete coverage nowadays... mostly because I'm working on a web site and much of my code just grabs data from the database, manipulates it, and spits it out. The manipulation code is generally well tested, but its a real pain to test the database code.

That being said, I can point out a case where unit tests saved me weeks of work...

I was working on a smallish project (4-6 devs) a while back and, after months of work we had reached a state of near completion. At this point, the folks in charge of the product decided that, instead of storing dates (and generating reports using them) in GMT, they wanted everything in EST. Given the product was built to handle large amounts of data/logs and generate information about that data based on timeframes, this was a fairly major change.

Over the course of the next few days, the development team went in and changed everything to deal with EST timestamps. What would have taken us weeks to do had we not had such extensive automated tests, took us just 3 days, allowing us to meet an aggressive schedule. We were able to jump into the code and start changing whatever we needed to; the unit tests giving us courage by knowing the system would complain quickly if we broken something. To this day, I use that experience as an example of how you can never truly understand the benefits of automated testing until it saves you... and it certainly did that for my team.

Answer 18

the biggest thing unit tests give you is confidence in your code. You know stuff works at a certain level of quality, and you know you can go in and change or rewrite something and not have things fail all over the place where you dont expect to. Verification is only a testrun away.

Answer 19

It saves me time, because when I run code TDD, it usually just works when it comes to integration time, so no need to spend agonizing hours debugging.

It also gives me confidence having a conversation with other developers claiming that API I created has bugs.

Answer 20

When you get to some critical mass of tests, a nice side-effect is often that if you are about to introduce a bug, it is likely to make some test fail, even if the tests aren't directly against the new, buggy code you are writing.

So you will be alerted to the bug you are about to commit before doing so, and you can then write tests against it and fix it right away.

(This is of course only true if you have tests that are not "just" very narrow test-one-thing-only tests, but I think that is more often the case than not.)