Are tests ugly?
-
I have written quite a few automated tests now with things like NUnit, and I find that they generally don't look very elegant. I find that code reuse is usually very difficult and code all ends up looking very similar. Books generally only show simple cases and in the real world with databases etc. things aren't quite so simple. A good example of what I mean is database stuff. Every table works in pretty much the same way, but they all have different fields and types so you can't reuse much code. I find that most of my code looks like this:
SetupConnectionEtc(); SetupDataForTest(); DoSomething(); ReadTheDataAndCheckEverything();Although the first line probably isn't unique, all of the others usually are. So if your application uses 20 database tables then you will probably end up with 20 files containing a ReadTheDataAndCheckEverything() function, as well as some of the other ones. What do people think? Am I doing something wrong or is there an easier way? -
I have written quite a few automated tests now with things like NUnit, and I find that they generally don't look very elegant. I find that code reuse is usually very difficult and code all ends up looking very similar. Books generally only show simple cases and in the real world with databases etc. things aren't quite so simple. A good example of what I mean is database stuff. Every table works in pretty much the same way, but they all have different fields and types so you can't reuse much code. I find that most of my code looks like this:
SetupConnectionEtc(); SetupDataForTest(); DoSomething(); ReadTheDataAndCheckEverything();Although the first line probably isn't unique, all of the others usually are. So if your application uses 20 database tables then you will probably end up with 20 files containing a ReadTheDataAndCheckEverything() function, as well as some of the other ones. What do people think? Am I doing something wrong or is there an easier way?I find testing (and writing tests) invaluable. In fact, it's the only reason I sleep soundly at night (no, really). I'm working on some low-level frameworky stuff (that has to work and has to work fast) and end up writing slightly higher level tests than the ones mentioned in your post. I find them to be more useful (i.e. akin to how my APIs are used) than traditional unit testing. To answer your question, I probably wouldn't write tests that check table reads and writes - instead, I'd write tests for the APIs that end up calling them. I hope this makes sense. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com