4 ms·

I like to be able to inject a 'filesystem' object into code for testing, so as not to have to use a real filesystem. This doesn't look like it supports that, wh

by rikkus 12y ago

I like to be able to inject a 'filesystem' object into code for testing, so as not to have to use a real filesystem. This doesn't look like it supports that, which is a shame. 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?

stinos 12y ago
Any other ideas on how to write testable code which uses this filesystem API? 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?
- rikkus 12y ago
  It's third party code I worry about, where it hasn't been written to expect a root directory. I can chroot on *NIX, I suppose. 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.
tedunangst 12y ago
namespace fs = test::filesystem;
blt 12y ago
templates. or write your own wrapper using virtual methods and take the hit in runtime performance. just like you would mock up any other C++ code that's not already behind a virtual interface.
euid 12y ago
You probably want something like pyfakefs[1], a reimplementation of Python's (old) filesystem modules for the purpose of testing. 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. [1]: https://code.google.com/p/pyfakefs/ https://code.google.com/p/pyfakefs/

by rikkus 12y ago

stinos 12y ago

Any other ideas on how to write testable code which uses this filesystem API? 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?

rikkus 12y ago
It's third party code I worry about, where it hasn't been written to expect a root directory. I can chroot on *NIX, I suppose. 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.

tedunangst 12y ago

namespace fs = test::filesystem;

blt 12y ago

templates. or write your own wrapper using virtual methods and take the hit in runtime performance. just like you would mock up any other C++ code that's not already behind a virtual interface.

euid 12y ago

You probably want something like pyfakefs[1], a reimplementation of Python's (old) filesystem modules for the purpose of testing. 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. [1]: https://code.google.com/p/pyfakefs/ https://code.google.com/p/pyfakefs/