Are test fixtures worth it in your automated testing strategy?

Building automated tests for green field projects is a breeze.

Or at least…it’s not as hard as taking code written by someone not even on the team anymore, and attempting to test it.

Legacy systems can make you sweat. Raise your hand if you know EXACTLY what I’m talking about. (And raise two hands if that part of the system gives you nightmares from time to time!)

Have you invested any time in coding test fixtures to automate your tests? Or do you work at one of those shops that STILL have a 27-page test manual that has you CLICKING THROUGH WEB PAGES to verify your code?

As a pro coder, it’s imperative that you invest in building test fixtures to improve the efficiency of your testing process.

What is a test fixture?

It’s a code construct that provides a fixed environment for testing. It includes everything required for a particular test, such as a setup routine, test data, and sometimes utilities methods to help manage it all. It’s the foundation upon which you build some, if not all, of your automated tests.

One more thing to build in order to engage with automated testing? Yikes!

Yes, it’s true that building test fixtures for legacy systems can be time-consuming. But it’s a valuable investment that will eventually pay off.

For instance, think of a system that scans electronic invoices and stores the results in a database. To automate testing for a system like that, a suitable test fixture might do something like this:

• Cleans out the appropriate database tables.
• Creates a new database schema that avoids collisions with other developers.
• Stages the test file in a specific location so that the parser can find it.
• Invokes the system.
• Waits (fixed time, or looks for some signal).
• Reads the final results from the database.

(BTW, this is EXACTLY one type of test fixture I built at my previous job, before joining the Spring team. It was quite painful to build.)