Timeline for Test Driven Development: A good/accepted way to test file system operations?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 9, 2015 at 20:37 | comment | added | Frank Hileman | The more I think about the test file system, the more I like it. | |
| Apr 9, 2015 at 7:46 | comment | added | James Anderson | @Doc Brown -- I am sort of assuming he wants to do dir, delete, and rename type operations all of which have edge cases which would be painful to mock. Also on modern hardware unzipping a a few small files into a directory is only a little slower than loading a Java class -- its all IO after all. | |
| Apr 8, 2015 at 21:35 | comment | added | Frank Hileman | I think file systems, if mocked, ideally should have a whole API written and maintained by some group, because you are reinventing the wheel, if you do anything significant with the file system. | |
| Oct 7, 2013 at 11:07 | comment | added | Doc Brown | Mocking out file system operations will create much (!) faster running tests than using a real file system, and if this is more "error prone" is debatable, I would say it depends on the implementation. Nevertheless I think your suggestion is fine for creating automated integration tests (which I typically would do first when not doing TDD). But the OP specficially asked for TDD, and TDD unit tests have to be fast. | |
| Oct 7, 2013 at 8:13 | history | answered | James Anderson | CC BY-SA 3.0 |