My other tactic is to create a temp directory at the start of a test and do _everything_ within it, then clean it up at the end.
Any other ideas on how to write testable code which uses this filesystem API?
My other tactic is to create a temp directory at the start of a test and do _everything_ within it, then clean it up at the end.
Any other ideas on how to write testable code which uses this filesystem API?
My guess is that either you will have to write it, or you will have to convince a C++ developer that it is worth writing cppfakefs.
Otherwise, you can build a test_root_dir RAII object that creates a directory in /tmp and does the cleanup automatically in its destructor.
not nice ones (or I must be missing something). Could either make all code take the API as a template parameter, or wrap the API in your own set of classes. Now often the logic you really want to (unit) test isn't the one directly accessing the filesystem but rather a layer higher? And in case of integration/system tests (or whatever it's called these days) wouldn't you rather use the actual filesystem, like with the temp directory you talk about? Can you provide a concrete example of what would be hard to test with this?
Perhaps I should go and have a look at how code using boost normally deals with dependency injection for testing. Maybe I'm missing something.
namespace fs = test::filesystem;