How to unit test function that modifies a file

Question

Custom class has file Write and Read methods. How can the unit test for write be properly validated if the only way to get the file contents is to call the read method?

Answer 1

1. Test Read() first using pre-existing test files.
2. Now that you know it works, use Read() to test Write().

---

Best Practices are less about being the best practice and more about avoiding bad practices. Bad practices like coupling too much code together in a single test such that you can't tell where the problem lies and such that multiple bugs can interact to cause failure. Unit tests, among other purposes, try to avoid coupling. But if you try to follow Best Practices as dogma, and concern yourself too much with what category of test everything is, you'll wind up doing some bad practices just to try and follow the Best Practices.

Reading and writing files are inherently coupled, writing isn't much use unless you can read it, and you have them in the same class so it's not an external dependency. The trick is to write your tests such that Read() and Write() bugs can't interact to cause a false positive. For example, if you did something like this:

file = Temp.file
content = Read(file)
Write(file, content)

assert_eq( Read(file), content )

Then if Read(file) has a bug which occasionally returns an empty string, and Write(file, content) has a bug which just wipes the file, you'll get a false positive from the assert. Whereas if you wrote it like so:

file = Temp.file
content = "The quick brown fox jumped over the lazy grey dog.\n"
Write(file, content)
assert_eq( Read(file), content )

Bugs in Read() and Write() cannot lead to a false positive (unless you're in a pass-by-reference language, in which case content should be declared constant). Though they can interact, which leads us to the next bit.

---

You can test Read() without Write(), so do that first to be assured Read() works before using it to test Write(). Pre-generate a bunch of interesting files to exercise Read(): Unicode, empty files, big files, special files, etc...

# Pardon my mish-mash prototype language
tests = {
    empty: "",
    just_newline: "\n",
    simple: "This test is not metal.",
    simple_unicode: "†Hîß †É߆ Îß µé†å¬¡¡¡ "
}

for (file, want) in tests {
    assert_eq( Read(file), want, "Read(#{file})" )
}

If your test suite features ordering, make sure the Read() tests run before the Write() tests. Now if you run your tests and Write() fails you can be fairly certain it's not because Read() failed.

Once you're satisfied Read() works, you can safely use it to test Write().

---

There are always couplings in your code and tests, without them you can't get anything done. For example, if Temp.file has a bug where it doesn't always an empty temp file that can introduce bugs.

The trick isn't to eliminate all couplings, the trick is to minimize them. With regard to testing, strive to test one thing at a time. Since the Temp class was presumably well-tested when it was installed, and because it's a standard and very well used class, it's safe to rely on it in your tests. In this way you build up an ever-increasing foundation of well tested code to build and test more code on top of.