I must admit that I often struggle with practising Test-Driven Development. In spite of using Ruby on Rails which makes TDD super easy because it's baked-in, I find writing tests to be so boring! It's like dental flossing; I know that I should do it but struggle to muster much enthusiasm.
If you write the tests first, they are your specifications for coding.
All the thinking has to be done when writing tests. "What should it do?" "How will I know it's done it?" "What interfaces does it have that will need to be mocked?"
Further, if you structure your tests using a simple naming convention (using "shoulds") you can more easily determine what's supposed to be happening.
See http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx for some thoughts on this.
If you write the tests last, they are boring, since you know the code works.
If you're bored when writing tests, then you're testing the wrong things. I'm writing tests when something failed, when I didn't understand something or when something new comes up. This way, my tests are never futile or to comply to an "100% code coverage" policy and I'm never bored.
Writing negative tests is usually more interesting than the "sunny day" ones. Think through all the inventive ways you could break your class (passing in null, values too big/small etc).
Not only will it give your brain a different angle to chew on it'll also make your class more robust since people will call it with null, big numbers etc etc.
First I want to write production code, so I strive to write test first : nor writing any line of code without a failing test. This is not always possible but at least it forces me to write tests.
Then I try to break the code I have written using boundary tests, negative cases, wrong API usage (e.g. missing or several initialization calls) ...
Also I run the test often ; the "all tests passed" message at the end makes me feel comfortable about what has been written so far ... and I'm also happy when I found (and fix) a bug.
Sometimes, I'm having fun with the names and the numbers I'm using for my tests (birth date, favorite player number, phone numbers ...).
If you are using TDD correctly, then you should write the test before you write the code. It should be a good test to ensure that the code you are writing works, and should be a small increment.
As such, it is really part of development. What is different from writing one unit test vs. writing one function that you need to implement your code?
Saying that you find writing tests boring, is like saying "I find writing I/O boring .. is there anything I can do to make it more interesting?" or "I find writing UI boring .."
Well, actually writing any kind of code can be boring, or interesting ... but that's more a function of the developer than of the code :) My friend is being forced to write code for a company, although he's not really a programmer, and his comment is "I don't see how you can do this all day!!!"
Since you are a developer, my feeling is that you do like writing code, so the real problem is that you are not correctly following TDD and making tests a real part of your development. Even though a framework may attempt to make this necessary, it is really up to you to correctly follow the process (i.e. write the test first) and to really integrate it with your development.
Then, it is really an insignificant part of the overall development, like checking in code, commenting, formatting - all of which some people might find "boring" but are necessary. It doesn't bother us because it is just part of development and we find development interesting.
I'm worried that this sounds like a code smell.
Are the tests boring because they're very repetitive?
Are the tests covering the same things multiple times? (i.e. the test cases don't just test one thing at a time so there's lots of repeated testing of the same things...?)
You might be bored because the tests are written at the wrong level of abstraction or they force you to do lots of busywork that isn't necessary.
It sounds like something needs to be refactored or at least abstracted so that each test expresses just what's new or different from the rest of the code.
If lots of tests seem obvious or tedious, there's something missing from the abstractions that you're using.
I'd start looking for patterns in the kinds of tests that you feel are boring or tedious and see if something can't be done - like creating a tiny test framework to help make those tests easier to write.
On examination, you might just need to delete some redundant tests and clean up the naming - so that it's clear exactly what you need to test and what you can rely on being tested elsewhere in the test suite.
This is all about trade-offs. I think it's worth re-assessing the kinds of tests you're writing and having a look at what alternatives there might be.
There's a case to be made that boringness isn't altogether bad. I'd say it's stronger with respect to your regular code than to your test code, but it probably applies to tests, too.
Excitement comes when you don't know what your code is doing, when you don't trust it, when every time you run it - or release it - there's that little guy sitting on your shoulder shrieking "No!". When you spend a lot of time in the debugger; when your code is too complex, tangled and gnarly (not in a good way) and scary.
Boredom may be the opposite of excitement, and seen in that light, boring is good. One foot after the other, predictable step after predictable step, we write nice simple reliable working code. Red-green-refactor.
Nice simple reliable working code is something I can get enthusiastic about.