This post originated from an RSS feed registered with Java Buzz
by Jon Tirsen.
Original Post: Test-driven development and AOP (writing a large system with TDD)
Feed Title: jutopia
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Ramblings on Java, AOP, TDD, agile and so on. some like it jutopic!
In my experience testing an AOP system is easier than testing a system built on more traditional techniques (EJB and so on). Partly because you can get a much higher level of reuse and modularization. Higher reuse means lesser things to test, higher modularization makes it easier to write tests. Partly because it's much easier to execute the unit-tests, you can easily set up a small AOP system for the purpose of executing a unit-test and the tear it down again, repeat a couple of thousand times for a larger system. Try that with an EJB container...
Although one might think so, TDD is not primarily about testing. It is a programming-strategy, just like object-orientation is a programming strategy (with extensive language support). The point with TDD is not to get a green bar; it's to get a red bar (and then write code until the bar goes green, and then refactor). One way of understanding this better is to read Kent Beck's latest book Test Driven Development: By Example. And practice, practice, practice...
TDD is hard. It has fundamentally changed the way I program. The last time that happened was about 10 years ago when I learned object-orientation (and the time before that over 15 years ago when I first learned programming). Learning TDD is a process that for me has taken several years, from writing small isolated libraries with TDD (about 3 years ago) to the point where I am now; building large systems with TDD. I'm still far from mastering it completely of course.
Kent Beck's book will teach you the core process in an isolated example (writing a Money-class). Writing tests for a large AOP based system may at first sight seem to be very distant from the techniques he presents. For example, how would one use the simple techniques to test an isolated Money class to test say complicated object-replication based on AOP to multiple servers over IP-multicast?
The trick is to make it simple. Divide and conquer. Isolate each part of the system into simple objects, define their interactions and test them ruthlessly and isolated from each other. Okay, AOP replication over IP multicast: That's gonna be an interceptor, a multicast forwarder, a multicast receiver. Code the unit-tests, red bar, green bar, refactor. One small step at a time. Run some higher-level integrations/acceptance tests. Did it work? No? Okay, isolate the problems by writing new unit-tests and get them running. Run the higher-level tests again. Iterate until complete.
Don't underestimate this though. Making things simple is really, really hard. Despite all these years of object-orientation, components, reuse, modularization we're still not really used to seeing a system broken down into small, small units. We view a system as a couple of monolithic pieces (in best cases) with kind of fuzzy edges. TDD guts all the details of this out in the open air, it forces you to define the interactions between every little class in minute detail.
TDD will not only change the way you program it will also change the end result. You'll produce something we call a test-infected system. It's a system that is better defined, simpler to understand, more maintainable and reusable, in short: higher quality.
Okay, that's TDD. For testing AOP systems I've got some basic "recipes" you can use, Rickard. It's specific to Nanning of course, but the same general ideas will probably work for your framework too. I'll present them in some coming blog-entries.
Previous Topic
