How do I start unit testing?

Question

I know that unit testing is desirable, and I am interested in doing unit testing. The only problem is I have no idea how, or even where to start really. So my question is: How do I learn about and start unit testing? Specifically I frequently write Java code in NetBeans and C# code in Visual Studio and am interested in what tools to use and how to get my feet wet. Can anyone offer any advice for an absolute unit testing n00b?

I know that there are a lot of somewhat similar questions out there but I am less interested in why and more interested in how.

Answer 1

Try to read on StackOverflow, tag unit-testing :)

• Is Unit Testing worth the effort?
• How to make junior programmers write tests?
• What is unit testing?
• How do you know what to test when writing unit tests?

Another entry point would be the tags junit and nunit

There are lots of question dealing this.

If you're searching books about Unit Testing, try this thread: Good C# Unit testing book. There the famous Kent Beck book is mentioned, "Test Driven Development By Example".
It's worth reading!

Good luck!

Answer 2

http://en.wikipedia.org/wiki/Unit%5Ftest

Answer 3

If you really want to understand unit testing (and get hooked), try it out, it should only take a few hours!

First, I recommend downloading a unit testing framework, such as NUnit (if you want to start with .NET / C#).

Most of these frameworks have online documentation that provides a brief introduction, like the NUnit Quick Start. Read that documentation, then choose a fairly simple, self-contained class for which you are responsible. If you can, try to choose a class that:

• Has few or no dependencies on other classes - at least not on complex classes.
• Has some behavior: a simple container with a bunch of properties won't really show you much about unit testing.

Try writing some tests to get good coverage on that class, then compile and run the tests.

Unit testing is simple to learn and hard to master (apologies for the cliché, but it is appropriate here), so once you've done this, start reading around: for example, guerda has provided several excellent links in another answer to this question.

Answer 4

A good start is to buy a good book where you can read about unit-testing.

I have a tips on a book called "Software testing with visual studio team system 2008" and it takes you trough the basics stuff and background to more higher levels of unit-testing and practises.

Answer 5

This Tutorial for writing JUnit tests in NetBeans should give you an idea how unit testing is done technically. NUnit for C# works pretty much the same.

For an advanced view of how to integrate unit testing into you daily development, the standard reference is Kent Beck's "Test Driven Development By Example". Here's a broad overview.

Answer 6

Start small.

Unit testing (and automated testing in general) isn't a silver bullet, doesn't always apply to every situation and can be a bit of a culture shock. That said, if you're writing software that you're selling or that your company relies on, I highly recommend adopting it. You'd be surprised how many professional development shops don't.

First, get comfortable the mechanics of creating and running unit tests with your development tools.

Then, start with a new (preferably small, but not necessarily trivial) class or method that you want to test. Writing tests for existing code has its own challenges, which is why you should start with either something brand new or something that you are going to rewrite.

You should notice that making this class or method testable (and therefore reusable) has an impact on how you write the code. You should also find that thinking about how to test the code up front forces you to think about and refine the design now instead of some time down the road "when there's more time". Things as simple as "What should be returned if a bad parameter is passed in?". You should also feel a certain amount of confidence that the code behaves exactly the way you expect it to.

If you see a benefit from this exercise, then build on it and start applying it to other parts of your code. Over time, you'll have confidence in more and more of your software as it becomes more provably correct.

The hands on approach helped get my head around the subject better than a lot of the reading material and helped fill in the gaps of things I just didn't understand. Especially where TDD was concerned. It was counter-intuitive until I actually tried it.

Answer 7

Check out The Art of Unit Testing by Roy Osherove, it's a good book for beginners since it starts at the very beginning.

Answer 8

Find-a-bug-write-a-test

The next time you find a bug in your code base, before fixing it, write a test. The test should fail. Then, fix the bug. The test should pass.

If the test doesn't pass, there's either a bug in your test, or a bug in your fix.

A person will never find that bug in your code again. The unit tests will find it (and faster than a person can).

This is definitely a small start, but it gets you into testing. Once you've got the hang of it, you'll probably start writing more tests, and eventually get a knack for how code will fail and which tests you need (for example: a test for every business rule).

Later in your progression you setup a continuous integration server, which makes sure your codebase is always solid.

Answer 9

I would recommend reading Michael Feathers' "Working Effectively with Legacy Code". Old code often ends up being code that's hard to Unit Test. Feathers' book is a great guide in how to refactor your code to the point that unit tests are a snap to write.

Not exactly an answer to the question you asked, but might be a missing step between where you are, and where you need to be to implement some of the answers others have given.