Testing edge cases in TDD? [duplicate]

Question

When doing TDD "by the book" we should only -- as far as I understand -- write failing tests. This means tests for unimplemented functionality.

I often find myself wanting to add tests for edge cases that expect to work with the current implementation. This means the test does not drive the implementation, it is merely there to confirm what I suspect and document the intent.

In "TDD proper", is writing these types of tests part of the "refactor" step, or are they not part of test-driving at all, and supposed to be added at a later pass altogether?

Thank you for your feedback on the question. I agree it was unclear. To clarify:

Note that I'm explicitly looking for references to the originators/popularisers of TDD. I can invent sensible ways to deal with this situation myself, so it's not common sense I'm asking for help with. I want to try to follow the original idea dogmatically for a little bit at first.

Also note that this is not because I've written too much code in response to a previously failing test. Kent Beck explicitly recognises in TDD By Example that if you can right the obvious, correct implementation right away, by all means do it.

It's then I want to verify that it is the correct implementation, by adding the other tests I would have added to drive the implementation had it not been obvious to me right away.

These are also not strictly redundant test cases, because different implementations might handle edge cases differently, but these are the choices I believe are correct, and I want to verify and document that.

Edit: Upon close inspection, Kent Beck actually brings this up in passing at the end of TDD By Example. If two tests exercise the same code path but with different inputs, the base rule is to delete one. However, both should be kept if one of the following conditions are true.

1. Both tests increase your confidence in the solution for whatever reason, or
2. They communicate different scenarios to the reader, that happen to be implemented with the same code path.

Answer 1

You write the test. The test passes without you having written any production. This means one of two things:

1. At some point in your past, you wrote more code than needed to pass the test(s).
2. The test is redundant. It is already covered by one of your other tests, or a combination of them.

#1 is simple: keep the test, you're done. In situation #2, you have a choice to make:

• Keep the test as documentation of the edge case.
• Add a comment to the existing test(s) that already covers the edge case.

Answer 2

In "TDD proper", is writing these types of tests part of the "refactor" step

No. Refactoring is about changing production code without changing it's behavior. It's not about changing or adding tests.

are they not part of test-driving at all, and supposed to be added at a later pass altogether?

There's no reason a failing test can't be a failing edge case. And no reason you can't wait until you have one before writing code that makes it pass.

You can see that clearly illustrated in Uncle Bob's bowling kata. It treats every feature as an edge case and creates tests for them before writing code that makes them pass.

But if you insist on adding an edge case test to working code I can give you formal steps for that. I documented them here. They support the principle that you should see every test both pass and fail before you trust the test.