.NET... How to TDD with flat files

Question

I have a project where most of the challenges are to ensure software works correctly with flat text files outputted by several external systems.

Mangement made decision to introduce Agile and TDD as a particular implementation.

I found that mocking input from the flat files makes no sense because the main issue to resolve is exactly correct work with those particular files.

E.g. if output in external systems change the unit test must fail.

Unit-testing the code abstracted from the files makes very little sense and create very little business value (as the abstracted code will take lots of time to be abstracted and in the reality will produce a hundred one line methods).

Just want to reiterate - the challenge is to keep a tight tab on the software being able to work with flat files and TDD is to make this verifiable at any time.

What would be the suggestions? How this can be organised, defined, implemented?

Answer 1

Include sample files in your test project, and test using those. I tend to build the files into the test assembly and use Assembly.GetManifestResourceStream to pass it into the code. Using a Stream or TextReader in the API also means you can do very small tests using MemoryStream or StringReader with the data in the test code itself. (Unless you need to worry about detecting encodings, using a TextReader is probably more appropriate than a Stream.)

You could do it all with StringReader, but in my experience if you end up with several lines of test data it can get quite confusing - separate files can make it easier to see the data involved.

Note that this doesn't check that the output of the external systems hasn't changed - as Pontus says, that would involve system/integration tests. However, you don't want to do most of your testing at that level in my experience. You should have a mixture of tests at different levels, but the higher the level of the test, the longer it's likely to take to run - and the harder it may be to set up.

You may want tests which only test the external systems: have a piece of sample data which you expect to receive from the external systems, and have one unit test of your code that tests it behaves appropriately, and one "external" test which calls the external systems and checks that they produce that exact file. That way, you'll very quickly be able to tell if a failure is due to your code changing or the external systems changing.

Answer 2

From a .NET perspective, flat file are essentially strings, so I would design most of my API around testing input and output strings.

If those strings get too large, you can embed them in separate files, but it is always better testing practice to reduce each test case to the bare minimum necessary to reproduce/exetute a certain feature.

Answer 3

This doesn't sound like test driven development or unit testing at all: what you're describing is integration monitoring and/or system testing of the external systems. Are you describing a production environment or a development environment scenario? If the text files change, who should adapt (your consumer or the producing system)?

Whatever you do, make sure you have a clearly defined contract specifying the format and content of the text files which form the interface between your system and the external ones. If possible, implement monitoring functions in the production environments which trigger a warning if a source system deviates from the contract.

Answer 4

Is there a specification for the format of the flat files?

If so, you should include sample files that have each feature of the specification, and write a test for each feature.

If the flat files do not conform to a specification, you can't really do TDD on them - you might always have a new file with an unknown in it. In this case you would have to write your own specification, (based on observation/research) and TDD against that. But you would still be open to unknown data breaking your code.

The moral? Make sure you have at least a working practice specification.