Unit Testing

Unit testing tools are code-based tests that exercise class level APIs, etc. Hence the term "unit" testing.

While Unit tests are important, I find that functional and integration tests give more "bang for the buck". Not only is mocking and stubbing often difficult and time consuming, it doesn't always give a clear picture. Granted, isolation is sometimes a key way to focus on the unit under test, but I don't think unit level code errors that common. Either through printf()'s, debuggers, loggers, or unit tests, developers tend to cover their interfaces at the basic level fairly well.

The real advantage of unit tests is that you don't have to sort through log files or step though a debugger every time to want to test an object. Unit tests are repeatable, documented, and easy to run, so you end up running them more often (often with every build) -- and that reusability is their key value, which pays off big in regression and refactoring.

The documentive aspect of unit tests is also a great boon, because you are actually exercising the APIs, and I can think of no better way to learn about some code. If unit tests are written as part of a use case story or design document, a la Fit? / FitNesse? . If tools like this were used more often, unit tests would become even more powerful, and help drive design.

In my opinion, Unit Tests are a great way to extend the compiler, and execute build tests, especially being able to do type checking on dynamically typed languages, and checking algorithms.

Many unit testing tools seem to be roped in to doing double duty as code-level functional and integration tests, because they exercise APIs and have handy reporting and grouping features. Some unit testing tools, such as TestNG? and SimpleTest? are also geared towards functional tests.

The key here is to separate your test suites into those that are designed to test integration and those that target units. That way you don't spend too much time re-implementing functionality in your mocks, and when you do mock, it is to specifically test in isolation.

It's okay to have a test suite fail if you know the functionality it is testing hasn't been implemented yet. In fact, if you do test first development, every test you write should fail (at least) the first time you run it. The other technique emphasized in agile is to not write too many tests in advance, because "You might not need it", or a quote approximately like that.

Anyway, because "Unit Testing" is sometimes used to mean "code-level testing", functional testing tools that are designed to directly exercise the code are included here. And because mocks and stubs are often necessary, Mocking tools are also included.

JUnit? (Java)

TestNG? (Java)

EasyMock? (Java)

NUnit? (.NET)

PHPUnit? (PHP)

SimpleTest? (PHP)

Test::More? (Perl)

Test::MockObject? (Perl)

Test::Class? (Perl)

Rake? (Ruby on Rails)

-- Main.aaron - 2008-02-23