Chapter 17: How Do We Do a Test That We Can t Do?

We encountered a real bug in the system that wasn t caught by our tests. The feature worked, but the GUI wasn t hooked to it. We don t know how to test that, but our rules of operation say that we must. What can we do?

We Need Better Customer Acceptance Tests

You ve now witnessed a couple of GUI- related defects. First there was that scrolling problem, and then when I implemented a feature I forgot to hook it up in the GUI, even though the tests said it was working. It worked for everyone except the users! Lately, I ve found myself running the GUI quite often, to be sure that it works, and that s bad.

Lesson  

Why is that bad, you ask? It breaks the rhythm. The rhythm one tries to set up is write a test and make it work, running the NUnit tests after every small change. The cycle is just a couple of minutes, and except for typing in code, it s all pretty automatic. When the tests run, we re confident that the software is just a little better. Click, click, click, it ratchets forward. If we have to run the GUI before we have that confidence, it slows us down. Running the GUI means we have to start it up, go to the window, type some kind of test stuff, look at it, and then shut the GUI back down. Wasteful, distracting, bad.

Of course, we would like to have a test, if it s easy to write. But we don t know how to write this test. This chapter explores how to think about writing the test, how to write the test, and how to make the learning for this test help us in the future.

It s tempting ”oh so tempting ”to skip a test when it seems too hard. Much of the time, we ll get away with it. Once we make the software work, even if it s a bug fix, it s not likely that we ll break it again. If we have to check it manually once in a while, well, we ll probably remember, probably have time, and probably see any problems that creep in. Probably. However, because the software is growing and the design is evolving, every missing test is a hole through which bugs can creep, not just the first time, but for the full duration of the project. The more holes we fill, the better the software will be.

At the time I m writing this, Chet and I have already tried to test the code we re discussing here, and we weren t successful. I m tempted to give up, and if you knew what we do, I think you d forgive me. Fix the problem, move on, be more careful in the future. We ve all said it, we ve all done it, and we ve gotten away with it too.

But this is a book. It s about learning and about sticking to principles, pragmatic principles, by all means, but principles nonetheless. So I m going to push on this issue just a little harder, and we ll see what happens. I think we ll find that it isn t as hard as we fear to write this test and that we ll see the value of it before the end of the book.