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?
Go with the extra classes. When testing it its easier to:
This doesn’t mean you don’t:
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