For example, I’m writing tests against a CsvReader. It’s a simple class that enumerates and splits rows of text. Its only raison d’être is ignoring commas within quotes. It’s less than a page.
By ‘black box’ testing the class, I’ve checked things like
- What if the file doesn’t exist?
- What if I don’t have permission on the file?
- What if the file has non-Windows line-breaks?
But in fact, all of these things are the StreamReader’s business. My class works without doing anything about these cases. So in essence, my tests are catching errors thrown by StreamReader, and testing behavior handled by the framework. It feels like a lot of work for nothing.
I’ve seen the related questions
- Should QA test from a strictly black-box perspective?
- Rigor in capturing test cases for unit testing
My question is, am I missing the point of ‘glass box’ testing if I use what I know to avoid this kind of work?
This really depends on the interface of your CsvReader, you need to consider what the user of the class is expecting.
For example, if one of the parameters is a file name and the file does not exist what should happen? This should not be dependent upon whether you use a stream reader or not. The unit tests should test for the observable external behaviour of your class and in some cases, to dig slightly deeper and additionally ensure certain implementation details are covered, e.g. the file is closed when the reader has finished.
However you don’t want the Unit Tests to be dependent upon all of the details or to assume that because of an implementation detail something will happen.
All of the examples you mention in your question involve observable behaviour (in this case exceptional circumstances) of your class and therefore should have unit tests related to them.