Since I've been doing some work on the disk.rs module, I've noticed the tests could be improced, both in what's being tested and the descriptiveness of the tests.
In this PR, I haven't changed the functionality of the existing tests, but I've made improvements:
Use googletest assertions + matchers: These have very nice, descriptive failure messages rather than 'left != right" from std.
Added descriptive messages in the assertions
Use tempfile::TempDir - the proper way to use the file system in tests (when the TempDir object goes out of scope, the directory gets deleted).
Change the test structure / names to be more descriptive.
Also, I've added a test for the refreshing functionality.
Just as a note, another way in which the tests can be improved would be to be more specific in what the tests are actually testing, i.e. currently all the tests check that getting a non existent key returns none, but ideally we should have one test for that, and then not tests that behaviour in other tests, i.e. each test should test one thing, and its name should explain what that thing is.
What I'd like to do, if / when I get some time would be to look into having a generic test suite for any cache, and then just plug any specific caching implementation (disk, memory, redis, etc...) into those tests.
Just as a reference: Luca Palmieri has a really nice set of exercises in his testing workshop, which is where I learned about googletest.
jaemk
commented
7 months ago
Since I've been doing some work on the disk.rs module, I've noticed the tests could be improced, both in what's being tested and the descriptiveness of the tests.
In this PR, I haven't changed the functionality of the existing tests, but I've made improvements:
'left != right"from std.Also, I've added a test for the refreshing functionality.
Just as a note, another way in which the tests can be improved would be to be more specific in what the tests are actually testing, i.e. currently all the tests check that getting a non existent key returns none, but ideally we should have one test for that, and then not tests that behaviour in other tests, i.e. each test should test one thing, and its name should explain what that thing is.
What I'd like to do, if / when I get some time would be to look into having a generic test suite for any cache, and then just plug any specific caching implementation (disk, memory, redis, etc...) into those tests.
Just as a reference: Luca Palmieri has a really nice set of exercises in his testing workshop, which is where I learned about googletest.