TDD and Unit Testing with Mock Objects ... in Java (vs Perl)

n1vux on 2005-04-29T23:54:14

I was in all day training today, a 1-day quick-step run-through of 2-day course on Agitar Agitator, a unit-testing Eclipse plugin, for testing Java, that does semi-automated unit-testing and also does bulk-build unit-test regressions and house-style-checking and code-coverage etc, and can even do daily SIT regressions. (Not much Perl to be had, but interesting none the less. It gave me a better feeling for hard-core fine-grained unit-test design as the Agile/Java/TDD purists intend it to be than I'd had from the Perl.com Kata articles.)



If I wanted to do Java development, this would rock. As something to have both our developers and our Build system execute, it looks very promising.



Agitator makes nearly-pure TDD  practical in Java.
(Or if you prefer chiasmatically: It makes pure Test Driven Development nearly practical in Java.)
To do nearly-TDD with Agitator, you have to declare the Class and methods before you can write the test, but you can write the test before the method body, all in the same IDE, which is pretty slick.

But since the majority of programming is maintenance and enhancement, nearly-TDD is usually good enough. And for maintaining legacy Java, Agitator will deduce a lot of the class invariants and test cases for you, way cool -- with full control to override and tune as needed. It has hooks and tools to mock simple things automatically and to do sophisticated mocking of the regular important objects, much like T:MO, DBD::Mock, T::MC, only with hooks into the IDE.)  This could actually be easier to use than Test::Simple. (*cue background cries* Heresy! )



For pre-existing projects, adopting jUnit testing "Big Bang" is widely considered to take too much work to scaffold a test, it's much more work than Perl's Test::Simple/T:H/T:M although partly that's because of the foliation of the Java class trees and visual program "designers" not designing for testability? There are other toolsets for making mock objects/classes and generating jUnit tests, and other tools for doing style/rule validation, but this has it all. They've figured out that they need to provide tools that are useful to the developer at the moment of writing code and while refactoring/debugging/enhancing, and useful to the Build/ConfigMgt team, and provide useful statistics to management.



A key point that bears repeating is that, as with jUnit,  Agitator is primarily designed for true unit testing: white box testing of just one class's methods at a time, under the assumption that its dependencies work. As with induction, one is allowed to assume all else is fine, and one need not, one would prefer not, to rely on (possibly broken) out-of-class componentry. Why? So that a class test failure implies exactly and unambiguously either a class method error or a class test error. (It's Bad enough that it might really be a superclass error, but we don't want to be distracted by a underlying layer error that should be caught by it's unit-test.) This may require replacing those interfaces with Mock objects either automatically or with custom factories. [No, that's not stubbing!] So, Yes, you can unit test server-side code on the developer's PC -- you don't need FTP, a printer, a DB, or active Unix daemon processes to unit test, only to Integration Test -- if the dependencies are mocked. (Like jUnit, Agitar can be (ab)used to run SIT tests and regression tests by driving the top level class with factories and not mocking anything. That's ok, but that's not Developer Unit Testing.)



I deduce from this that the House Style Rules should include that all complex subsystems that aren't intrinsically trusted (JDBC) must come with Unit test set (or have one added); each should provide a TestHelper class with factories; and that the rule for what to mock is whatever has Unit tests of its own or is trusted but complex. The little things like "string" one obviously doesn't mock.



The downside is that it doesn't work with EPIC -- it's Java only. (And it is nowhere near Free or free, if either is important to you, but then, it's Java for the enterprise, so that's no surprise.)



Interesting quotes found on web on this topic...