How Can I Make Testing Software More Stimulating?

An anonymous reader writes "I like writing software. In fact, I revel in it. However, one thing has always kept me back from being able to write the best software I possibly can: testing. I consider testing to be the absolute bane of my existence. It is so boring and un-stimulating that I usually skip it entirely, pass the testing off to someone else, or even worse, if I absolutely have to test, I do a very poor job at it. I know I'm not that lazy, as I can spend hours on end writing software, but there's something about testing that makes my mind constantly want to wander off and think about something else. Does anyone have any tips on how I can make non-automated testing a little bit more stimulating so I can at least begin to form a habit of doing so?"

Comments

It may not be more stimulating

[NEDHead]

But you should be writing the test as you write the code

BDD

[Dishwasha]

First off, don't do non-automated testing. It's unnecessary. Do Behavior Driven Development with Cucumber http://cukes.info./ It's massively more fun than unit testing.

Re:Too close to the subject...

[SpinyNorman]

The developer should unit test, and the test group should system test. The two are complementary.

The test group will hopefully test the software in ways you never thought it would be used, but you'll hopefully have tested every code path and end case that only you are aware of from having written it.

Of course the developer can system test do, or at least contribute test cases.

You need to get into Test Driven Development

[CodeBuster]

Have you given Test Driven Development and NUnit a try? If you haven't heard of these things or taken one of the TDD frameworks out for a test drive then you owe it to yourself to invest some time. The software industry in general and the .NET community in particular is moving towards automated unit testing and Continuous Integration. You should get on this train too.

Re:Too close to the subject...

[FooAtWFU]

It's hard to effectively test after you've written code, because it is really boring. So I like the "test driven development" approach. You write the test first (or shortly after some very skeletal code) and when it passes, you know that you're done. (Well, or that you need to write more tests.) The time spent writing tests doubles as time to review and internalize the requirements of the task ahead of you. Benefits of the approach include extensive unit test coverage (which provides cover for you when you're refactoring) and uncovering (or sometimes even anticipating) boatloads of small bugs, long before they even hit QA.