Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

n1vux (1492)

  (email not shown publicly) ... x.cgi?BillRicker
AOL IM: n1vux (Add Buddy, Send Message)
Yahoo! ID: n1vux (Add User, Send Message)

Only started with Perl4 and Perl5 in 1995. I was doing AWK etc for 12 years before that, and resisted switching. I've been doing OO since before C++ hit bigtime, with Objective-C and SmallTalk, so I really like the (no longer new) Perl5 OO style; and the Lispish Map style is also an old friend. What do I hack with Perl? All data that passes my way; systems monitoring scripts at $DayJob, weather data at night, and I cheat on NPR word puzzles. Member: [] [] /. LinkedIn []

N1VUX is my FCC-issued ham radio callsign.

Journal of n1vux (1492)

Friday April 29, 2005
06:54 PM

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

[ #24458 ]

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 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...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.