Timeline for Test Driven Development: A good/accepted way to test file system operations?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 18, 2018 at 12:02 | comment | added | trixn | @Ark-kun The intention of mocks is to hide these kind of file system caused bugs for the unit under test. So this is not con, it's a pro in terms of unit testing. Otherwise the unit test would test something outside of its scope (the file system integration). The answer nowhere suggests to only do unit testing of domain code and get rid of all integration tests that could be able to detect this kind of file system related bugs. | |
| Mar 14, 2017 at 0:57 | comment | added | Ark-kun | @DocBrown I just meant that for almost all file system caused bugs I saw in my life, most mocks will hide them. For structured data the integrity is very important. I do not think the OP should use some mostly-broken ad-hoc thick mock instead of thin wrapper around a sandbox. Actually I just came here because I found a small library to be thoroughly broken in many places and its' 1000++ unit tests were rather useless as the file system was not faked good enough. | |
| Mar 13, 2017 at 14:09 | comment | added | Doc Brown | @Ark-kun: the OP asked about how to apply TDD to his situation. TDD does not mean doing no other tests, or fewer other tests. | |
| Mar 13, 2017 at 13:34 | comment | added | Ark-kun | Mock the FS operations? And then, after shipping your product you realize that any write corrupts the database if the disk runs out of space. | |
| Jul 13, 2016 at 6:24 | comment | added | Andrew Savinykh | So effectively we resign from testing the actual class that interacts with file system, database, etc... instead we create a different implementation with the same interface as a mock/stub, but the actual class we leave without any kind of unit testing, because we believe that we cannot unit test it and should do integration testing to test it instead. Is this correct? | |
| Feb 19, 2016 at 14:46 | comment | added | Jules | @soru right, so you create a thin layer around files & folders with an interface defined such that all domain-specific operations are on the client side, and the implementation side is trivial enough to be confident it works without unit testing (integration tests will still be required). Similar to the idea of a Humble Dialog in ui code, or using a mock Repository in code that operates on persistent objects. | |
| Apr 9, 2015 at 1:35 | comment | added | soru | But it sounds like the business logic is defined in terms of files and directories. So the stuff that calls the file system API is the stuff that needs testing. Testing any related non-file business logic does not need mocking; just test it. | |
| Apr 9, 2015 at 0:00 | comment | added | sleske | @soru: That's not what this answer recommends. It recommends first creating interfaces, then mocking the interface. So you do test the business logic, but not the filesystem interface. | |
| Apr 8, 2015 at 22:02 | comment | added | soru | TDD does not recommend mocking the implementation of the unit under test. See (e,g) [URL redacted -- site redirects to one that is not appropriate] | |
| Oct 7, 2013 at 6:07 | history | answered | Doc Brown | CC BY-SA 3.0 |