TDD in a text file import project

Question

I'm just starting, and yes, i haven't written any tests yet (I'm not a fundamentalist, I don't like compile errors just because there is no test), but I'm wondering where to get started on doing a project that parses fixed length flat file records according to an XML mapping, into a class that represents the superset of all file layouts, before writing (with transformation) the class details to a DB table.

There are so many external factors, and I don't want to mock them all, so where or how would be a good way to start test driving this project?

Answer 1

Well, you want to do testing but you don't want to mock. I believe that it leaves you to write integration tests or acceptance tests. It means that you have to do a lot of setup in your tests that probably will make your test brittle and hard to maintain.

I would really recommend to mock your external dependencies. It will make your application loosely couple and I believed it's going to be easier maintain in the future. Plus your tests are going to be much more manageable.

There are lot of Mock Frameworks out there that can help you. I have to admit that if you never done that before there's some learning curve. But we are in software development business and there's always something new to learn.

In case you decided to invest some time to learn testing with mock, you can start with this article.

Good luck.

Answer 2

It's all about decomposing the problem into parts. Some examples:

• File/stream reader
• Input mapper
• Input mapper loader
• File layout
• File layout collection
• Data access layer

Try to give each class a single responsibility, determine its dependencies, and inject those in. That, with the help of mocks/stubs, will permit you to test each class in isolation.

Answer 3

Two techniques I've found useful for testing IO-based classes:

• Where possible, talk in general terms like StreamReader and Stream rather than filenames. It's easy to create a StringReader or a MemoryStream in tests and provide the data that way.
• Sometimes you need more data than you really want to embed in literals in the code. In that case, add test files (sometimes both input and expected output) as embedded resources, and use Assembly.GetManifestResourceStream to get the data at execution time.

Beyond those general points, TrueWill's advice sounds very good. If you can split up the bigger task, writing the unit test for each individual bit sounds like it'll probably be easy - with the exception of the database access, which is usually a pain. If you can make the database part as small as possible, providing all the data from another easy-to-test class, that should make life simpler.