[TIP] 5 lines of code equals 30+ lines of single test

[Martin Pool]

To answer this at a different level:

You can't write every possible test.  It is most useful to write tests
that have a reasonable cost, are deterministic, and are likely to find
bugs that would have a high cost if present.

So if you think about this function, what kind of bugs could possibly
be present?

 - It doesn't open the file
 - It doesn't read the whole file
 - It doesn't handle path manipulation as intended
 - It doesn't close the file when it's done
 - Platform-dependent bugs in path handling or file opening
 - It reads the file as unicode when it should be bytes or vice versa
 - Unicode filename problems
 - it doesn't handle the 'local' kwarg
 - it doesn't mesh properly with whatever handles the other args and kwargs
 - ....

It is better to write tests that don't depend on how the thing you're
exercising accomplishes its work, as much as possible.  (Obviously at
different levels of testing you treat different things as black
boxes.)

I think it's a bug you're testing that os.path.join is called.
Perhaps, later in this code's life, there is a good reason to change
to using your own path manipulation functions.  This test will then
fail.  We would probably prefer that it continues to pass _as long as
the result is equivalent._

Similarly for testing os.open and getcwd is used.

There's a time and a place for mocking (or I would prefer, faking)
interfaces but os.open is so cheap I think you might as well just use
it.