Hoisting test code into production
A while ago I mentioned how I had hoisted a mock object up into production code because it only needed a few changes to make it usable as real code rather than just test code. This last week we’ve done this again…
Our system was designed with testing in mind; we’re loosely coupled and, consequently, have lots of interfaces that we can implement any way we want. To allow us to test large chunks of the system together we deliberately plugged the external data sources in right at the top. We could test the single application level object that was the ‘above’ of our parameterise from above by plugging in mock data sources and running a suite of tests. These tests covered 90% of what the running system did; last week we hoisted those mock data sources into the production code as configurable data sources and managed to test our entire application running from pre-canned data…
The system interacts with many external systems through some fairly hairy COM objects. Some of these COM objects are in VB (aww, how sweet) and when we ran our system under memory leak tools these external data source COM objects tended to make the system crawl along extremely slowly; what’s more the VB objects didn’t seem to like playing with the memory checking tool (no idea why) and, in general, the long running leak locating tests tended to die before they provided any useful information (but, after running for hours and hours and hours - figures…) By hoisting some mock objects into production and writing some instrumented data sources we can now configure the system to run in one of three ways.
-
Run from live data - the real system, running for real with real data.
-
Run from live data and save copies of it all to disk for later consumption.
-
Run from data that we’d saved to disk.
When running from data that has been saved to disk we eliminate all of the ’legacy’ COM objects from the system. The system simply loads data from disk rather than crawling off through a tangle of VB. The memory leak tests fly and we can take a day’s worth of saved data and ‘up the tempo’ and run it through the system in an hour or so… Cool stuff. The instrumented system also seems to be useful for examining exactly what queries the system is generating (we dump queries as well as results) and has allowed us to spot some weirdness and inefficiencies in our data retrieval…
The code we hoisted into production wasn’t used as is, it needed work, but because we were experienced in writing this kind of ‘dummy’ code, the work was easy; we also started from a position of being 80% complete…
If the system hadn’t been designed from day one to be testable then we’d never have been able to slip in some dummy data providers at the last minute. By making the system testable we made it flexible enough to accommodate change…
The memory leak was in someone else’s code, by the way ;)
