Where do your tests come from?
Paul and I were pairing today, and we had just gotten a green bar. The GUI code is frankly a bit bewildering to me (typically a non-gui, non-web guy) since adding a new GUI class involves creating a lot of bits and pieces and fitting them into a framework of parallel hierarchies that does not fit in my head (yet). Sometimes it's just a blur rather than a learning experience.
I know that GUI coding is supposed to be rewarding and fun, but it always seems like an awful lot to go through for a very small bit of satisfaction. I was struggling to acquire and maintain context, while my partner was flashing through a number of similarly-named files.
The odd bit is that we have a lot of classes that basically work the same way, in this somewhat-complex framework of ours. It seems that it should be a more orderly process to add yet another software citizen to a community that is already established. Instead, it seemed almost random to me.
As he started talking about the next test, I was impressed with the fact that we didn't have a real game plan, cookbook, or any other real guide to tell me how close (or far) we were from being done. Indeed, I couldn't remember which classes we'd already created or where we'd hooked them in so far, let alone choosing which test to run next.
So I blurted out a question which continues to haunt me, "Where do your tests come from?"
It meant a lot of things at once:
- how do you know where you are?
- how do you know what's next?
- are you keeping some mental checklist?
- is there an example you're copying?
- are you just making this up?
- what major effects or side effects are you considering?
- what is it that "might possibly break"?
- what is still incomplete?
- the biggest question: How do you know?
I suppose that perhaps the quality that determines who can do TDD is simply that of a really good memory that can handle a pretty deep stack. I hope that's not it, because it's not trainable and may not be learnable. I don't even know that it's sustainable. Or reliable. It's disconcerting even while being laudable and amazing.
So this is the question that bothers me most in all of TDD. Where do your tests come from?
!commentForm
I keep a little checklist on an appropriatly swanky web2.0 company's website, that when I start working on a new feature, I start a new checklist and write out all the tests that I think could apply to the feature. Then I order them from trivial, can bowling all zeros return zero, to hardest. As I write more code I add more tests to the checklist, and eventually finish the list.
Truth be told, finish doesn't usually mean I write all the tests I think of, usually I finish when the next test on my list is less important than some other work I've got to do.
(presumably my future free time would allow me to finish these, when they become more important than me posting on a blog :)
Truth be told, finish doesn't usually mean I write all the tests I think of, usually I finish when the next test on my list is less important than some other work I've got to do.
(presumably my future free time would allow me to finish these, when they become more important than me posting on a blog :)
I will try this as an experiment I think (sometime in the next 3 weeks):
I suspect that I'll end up just about where you'd expect to end up -- the essential ones done, the junk skipped. But I'll maybe have a better feel for my progress and the amount of work left to do. And I'll have a checklist, which will make me feel better.
- I'll make a short list of tests that I intend to write.
- I'll write them, starting with the first, and make them run.
- As new tests occur to me, I'll add them.
- As tests on the list are obviated by other tests, I'll remove them.
- As tests look wrong or silly, I'll drop them
- I'll quit when all the tests still on the list are completed.
I suspect that I'll end up just about where you'd expect to end up -- the essential ones done, the junk skipped. But I'll maybe have a better feel for my progress and the amount of work left to do. And I'll have a checklist, which will make me feel better.
It does make me feel good to check a checkbox, but much more so, to know that I've capture everything I've so far thought of that is the chasm between me and finished.
tadalists/backpackit is a pretty good checkbox repository.
tadalists/backpackit is a pretty good checkbox repository.
I'm not one to talk from personal experience on this, but in reaking Kent Beck's Test Driven Development, I believe he states that the checklist is an essential part of the process. He uses one extensively in his examples.
Where do the tests come from? They come from your understanding of the problem, and of the solution you intend to build.
Consider it the other way around. If you weren't writing tests first, then where would your code come from? Clearly it comes from a plan you have to solve the problem. You have had to understand the problem, and contrive a solution, and then you've had to decompose that solution into an actionable plan to write code. TDD adds one more step. Now that you have an actionable plan to implement the solution, TDD demands that you unambiguously specify that plan before you execute it.
TDD is like when pool players call their shots. When a player says "8 ball in the corner" s/he is really stating a test. So a test is a statement of your intent. You must have the intent in order to write the test. If you didn't write the test first, you'd still have to have the intent to write the code. The intent is the same in either case. TDD just forces you to be explicit about your intentions.
What are your intentions, sir?
Consider it the other way around. If you weren't writing tests first, then where would your code come from? Clearly it comes from a plan you have to solve the problem. You have had to understand the problem, and contrive a solution, and then you've had to decompose that solution into an actionable plan to write code. TDD adds one more step. Now that you have an actionable plan to implement the solution, TDD demands that you unambiguously specify that plan before you execute it.
TDD is like when pool players call their shots. When a player says "8 ball in the corner" s/he is really stating a test. So a test is a statement of your intent. You must have the intent in order to write the test. If you didn't write the test first, you'd still have to have the intent to write the code. The intent is the same in either case. TDD just forces you to be explicit about your intentions.
What are your intentions, sir?
In my world, I have an understanding, as Bob stated, of the problem. I know what I think its supposed to do and thats where I start. I test what I think itll do. 99% of the time I use session based exploratory testing (SBET we call it). I have a small idea of where I want to go and then I see where it leads me. Im not supposed to get off track but in my world of bug discovery, but sometimes its very hard to stay on task. I know that whether I script a test of am doing manual testing, I know there is something there. Most of the time (dont laugh) I just can feel that there is a problem in a particular area. You really have to use all your senses when testing an object.
Add Child Page to WhereTestsComeFrom