I’ve been working with my new tools wiki for one-shore.com , Twiki; importing entries from dokuwiki, and adding new ones. Anyway, the summary for the unit testing tools entry got a bit long, and I thought I’d move it on here in case anyone wants to read it (like me, sometime in the future.)
Maybe I should offer some commentary on all tools categories in the wiki. I’d like to keep it factual, but I don’t know that many facts, and if it becomes an article or tutorial, it should be moved to the appropriate section of the website.
Of course, I’d love comments, reviews, and details on the wiki from whoever would like to add their insight/experience/rant about any development, testing, or PM tools.
Eventually I’d like to write an article with ideas from this blog post/wiki entry:
Unit Testing
Unit testing tools are code-based tests that exercise class or module level APIs, etc. Hence the term “unit” tests.
Unit tests provide a way to test code in isolation, in a clearly defined, repeatable manner, and ideally provide techniques for easy execution, grouping, and reporting.
Many unit testing tools also seem to be roped in to doing double duty as code-level functional and integration tests, because they exercise APIs at the code level, are easy to run, and have handy reporting and grouping features. Some unit testing tools, such as [[TestNG]] and [[SimpleTest]] are also geared towards functional testing.
Because “Unit Testing” is sometimes used to mean “code-level testing”, functional testing tools that are designed to directly exercise the code of integrated units are included here. And because mocks and stubs are often necessary, mocking tools are also included.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.
The key is to separate your test suites into those that are designed to test integration and those that target the units themselves. 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.
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.
List of unit testing tools:
[[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)
Recent Comments