Over the years, I’ve read a little about unit testing and heard it talked about at WWDC once or twice, but never thought much of it and didn’t see much of a need for it. Recently I’ve started to look at it again and have done a little research on the concept. I found a reference that seems to sum up the flaws of unit tests.
A test is not a unit test if:
It talks to the database
It communicates across the network
It touches the file system
It can’t run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing config files) to run it.
Of all the projects I’ve worked on over the years, most, if not all, of them have had external dependencies such as network connections, handheld devices, or files on disk and therefore most of the unit tests I’d write adhering to the above rules, would barely exercise the app. If I wrote unit tests to simulate networks, I’d have to hard code in test data which lets us test one path in our app if we assume the data on the network never changes which is quite unlikely.
So, effectively unit tests are useless. I’m sure that someone will argue with me about this point, but if we assume I’m correct in the limited utility of unit tests, can tests be written that are useful?
Of course, we can write tests using the unit test framework (like OCUnit in Xcode 4). The test aren’t unit tests, they’re more like functional or integration tests that have external dependencies. This will let us test error conditions and see how different parts of the code will act in a real world environment.
It appears that Wil Shipley of Delicious Library fame seems to have similar views to me on this topic. However, I’m not opposed to functional or integration tests.
I don’t discount the utility of writing “tests” and will be writing some to test chunks of my code, but for the projects I’ve been on and expect to be on, unit tests have very limited utility and are possibly a poor use of limited resources.