Re: Modifying test system?
Having something like a configurable background as part of the original design is fair enough. It doesn't touch any of the code responsible for doing the actual work. Just don't make it user configurable.
In fact I've seen something similar where there were a number of production systems sharing a lot of common code and hence user interfaces but operating on different databases. The background was specified in the database so that the users would always be aware of what they were working on.
But the same gig underlined the point about making sure that the test system tests the actual code that will be live. My client was a subcontractor processing data from other subcontractors and it was one of several where the data feed was to be XML so there was a bunch of systems sharing common code for handling that. On one contract upstream wasn't ready to generate XML when testing was due to start and wanted to send fixed width files instead (the data wasn't very complex so in this instance XML was overkill).
Fair enough, we had to have some end-to-end testing in place to keep to schedule. I wrote a front end, in fact a two stage front end, which converted fixed width to CSV and CSV to XML, all parametrised and set up to generate the XML to the project's schema with both steps being trivial to implement and based on the in-house class hierarchy, etc. This enabled our test system to use the eventual live code to do the XML import and as a by-product provided modules to allow the client to import fixed width or CSV data should this be a requirement for a future contract.
My client's development manager - yup, development manager! - couldn't understand why I didn't rip out the entire XML processing code, which was a large part of the entire custom code, and implant a completely new fixed width file processing code just for testing. In fact, it was the stress of dealing with that particular manager's bad decision making that persuaded me retirement time had arrived.
Biting the hand that feeds IT
