Question

I’ve recently asked a question regarding best ways of separating business logic from data access to make application testable (here). Thanks to Jeff Sternal, I’ve created interface for the data access and passing its concrete implementation from the application top level to BL. But now I’m trying to figure out how can I separate file access methods from business logic.

Let’s say I have a function that loads data from a database into dataset, formats loaded data (formats are stored in some external xml file) and finally serializes dataset to a file. So, to support testability I need to move all the functions that access file system to some interface. But first – I find it quite handy to just call dataset.WriteXml(file), but for the testability I have to create interface and move dataset.WriteXml() to its implementation, which looks to me as unnecessary layer and makes code less obvious. And second – if I move all methods that access file system to a single interface, it will violate SRP principle, because serializing\deserializing datasets and reading data formats from a file seems to be different responsibilities, correct?

Answer 1

Go with the extra classes. When testing it its easier to:

• For the dataset exporter/writer – check the modified data is passed to the writer
• For the formatter – check the formatting logic

This doesn’t mean you don’t:

• Use dataSet.WriteXml, you just do so in the v. simple class … as a one liner, you don’t need to do add a focused integration test for it … but if u l8r on store say in an external system, u might choose to do so in that other implementation, without affecting the other code
• Use separate classes for a dataset exporter/writter than for a simple file writer.

As long as you are using v. simple dependency injection, you are really just keeping everything simple … which will get you better results both in the short and in the long run.

Ps. not hitting the file system during tests is important, as when your number of tests grow you want them to run v. fast, so don’t be misguided to what appears at first “quick” accesses for a test