I'm about to write a program and test(s) for it. This question is about how to structure the top-most level integration test.
At the top level, the main program takes a chunk of data, and outputs another chunk; specifically, it takes in a whole load of business data such as wages, material costs and so on from a configuration file or similar, and produces a single XML file listing products, their prices, product-specific data, data on groups of products, and quite a few other things.
So what should this top-level integration test look like?
I subscribe to the idea of writing top level tests before anything else, acting as a specification of the interface for the code to be programmed - and to a far lesser extent to catch bugs (since at a given level, the set of tests should be more thorough than the level above, so most testing should be done in unit tests.)
I am contemplating writing a single top-level integration test here: feed it a complete configuration file, then test that the XML it outputs is as expected.
So, using PHPUnit, I would have a single TestCase class with a single test() method. And that method would assert every expected XML tag and their contents, and also fail if there are unexpected tags. But only one combination of configuration inputs would be tested. (Or perhaps a couple if it really seems necessary at a later time).
This way, the test would serve as a signpost to keep programming efforts focused on the end goal.
And the test would be easy to read (and maintainable?) since it just consists of a very small test method, an input configuration file and an expected output XML file.
The problem is I have read tests should always be kept small - e.g. at most a handful of assert statements per test method. But then testing a whole XML file like this would be a code smell?
