I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.
Agile’s crossed Geoffrey Moore’s chasm – it’s going mainstream.
Brian Marick’s 4 minute lightning talk here explains why this might not be such a good thing: the early majority is tiny, and the “early adaopters” (people interested in big wins) are currently wasting time and effort attempting to convert a bunch of people who don’t really care. Instead we should just give up on the “late majority” and concentrate on ourselves.
How about using Selenium IDE as a tool to help users / manual testers submit the “how to reproduce” part of a bug report? I haven’t tried this out – just an idea a friend mentioned down the pub the other night.
Don’t know about you but I always test, build, package, test, and deploy the entire app to release a change in config, so why is the Spring approach better than assembling my objects ourselves in code? Initialising our objects in XML is a popular option, so it must give us something.
One thing that Spring does not provide is Dependency Injection. Dependency Injection is a style of coding, and you don’t need a framework to code in a particular style. If you’re puzzled about how to do DI without Spring, take another look at the Gang-of-Four Abstract Factory and Builder patterns. Coding factories is no harder than writing XML, and even makes it easier to write chunkier Junit tests for assembled components.
What I think we get out of coding our factories using Spring XML is permission to relax the Java / OO rules during initialisation. At application initialisation we get to indulge in (lovely) dynamic typing, slightly more worrying global variables, and even the downright alarming excuse not to write tests for behaviour.
If there’s a type error it happens at runtime: its dynamic. And you’re still coding in a statically typed language because….. (*).
The requirements change and your WidgetRepository, configured in the widget.xml, needs to get hold of a database connection to the “ooplah legacy system” configured in “ooplah.xml”. No problem – just pass in the “ooplahDataSource” bean id and you’re laughing. One of your Ooplah components needs a Widget, and the “widgetRepository” bean is ready and available. It’s all one big pot of bean soup.
Ok Spring does support hierarchical contexts, but know anyone making much use of them to partition their apps?
So you’ve factored your code into small composable units? Well done. Your users will be delighted. And each unit is thoroughly unit tested? Excellent. (I bet you used Mock Objects, but I’ll let that go for now). Well the XML stuff is just config, so you don’t need to test that.
WRONG!
If you define behaviour by plugging your objects together in different ways then that configuration is code. No matter how well you’ve tested the individual object you need to test how they work together.
Even if you’ve automated end-to-end tests in place, you might ward away hours wasted at the debugger and fear of change by having some chunkier unit tests around your aggregate objects defining a particular behaviour.
A good side-effect of those chunkier tests is that they tend to encourage modular configuration with high adhesion within a single config file, and a few external dependencies stubbed for the test.
(*) .. because they’re paying me ;-)
Just joined Twitter out of curiosity. Yeah, I know that’s what they say about heroin. I’m not really sure what it’s for, or what I’ll get out of it. I suppose it goes against my assumption(**) that no-one’s really interested in what I’m doing.
We’ll see…
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)