Pathological Development (The World According to Garthe)
Alex Miller has an interesting post on the concept of the Garthe JVM. Named after the evil twin of a TV show protagonist, the Garthe JVM would support the Java Memory Model but be otherwise evil (e.g. nefarious thread scheduling and bytecode re-ordering).
An entire JVM isn't realistic for me (those Terracotta guys aim high), but the notion of injecting some evil into your project, for testing, can be really illuminating, and even fun. (Note: this is app testing, not testing the memory model semantics.)
The Original Pathogen
Many moons ago, I worked on a web project that used a home-grown HTML templating framework. This was pre-JSP, but they used macros which were a precursor to JSP taglibs. The dev team had one pathological macro that would explicitly throw an exception. Needless to say, it was undocumented.
However, it was very useful. The app was in C++ so memory leaks and exception safety were key concerns. When testing for these factors, one shouldn't wait for evil to happen: one has to be evil. One has to be Garthe.
Garthe Injection
These days, with IoC containers and mock testing objects, there are variety of tools that one can use to inject some pathological behaviour into an app.
How about this world, according to Garthe:
- an implementation of a ORM layer where the DB goes down every 5 minutes
- network latency is most definitely not zero in Garthe's world: it can be infinite, and there are network-based objects to prove it
- an exception of some type T really are thrown from strange corners of the design
- a homegrown (undocumented!) Swing/UI component creates its own thread and attempts to process UI events on that thread, and not on the EDT
Precisely: how does your app handle it? If you asked the team, just as a thought experiment, would they know? If Person A and Person B have different speculations on the outcome, what does that mean?
This pathological development is a great conversation starter, and in terms of role play, it's fun. Just be sure to mark the code very clearly or, better yet, have a "skull and crossbones" jar/project that contains the source.
2 comments:
Cool. I've done things like this before to do fault injection (randomly make your data layer throw a SQLException for example).
Definitely good and important stuff for system testing.
In an enterprise environment within a company that has a large code infrastructure and shared code, it would be great for the testers to start a project with programmers to create a "Garth" environment for evolving programs. Most places have "local", "dev", "test", and "production" environments, but I think it's a great idea to have a "garth" environment were nothing works correctly.
This will ensure before going to production that each application handles all the possible problems the testers and programmers can come up with in the garth layer.
Post a Comment