Programming Workflow with Unit Testing but Without TDD

I always had the notion that when you do unit testing, you have to do TDD. However, after months of开发者_Python百科 reading about it, it turns out that is not the case. The standard TDD workflow goes like write tests first, then write the code to satisfy your tests, then iterate.

The problem is, I can't seem to imagine how to do unit testing but not following the TDD workflow. Do you know of any way I can do this?

TDD is first doing small design steps first, for example thinking up your "desired" method signature, then writing a test for it, then implementing it till green, then refactoring if necessary.

This workflow makes sense (to me anyway).

Alternatively, you can write test afterwards to "prove" some confidence. But you are missing the small design steps and then the emerging aspect, by design, implement to green, refactor, your design/implementation is emerging and at the same time you have your test to prove correct behavior.

These are my thoughts but if you feel this doesn't suit your question then please be more specific about your needs.

Working with unit testing without TDD can be as simple as writing a few methods, then writing some unit tests that prove they do what you think they should. Once the tests are in place you can optionally refactor you code to improve the implementation, safe in the knowledge that if you introduce any bugs the tests should catch them. Alternatively, you could write all the code, then all the tests, but this has the disadvantage that if some of the tests break it could have been ages since you wrote the code, and so finding and fixing the problems will be harder.

TDD has a three stage cycle: Red (write failing a test), Green (write the code necessary to get that test to pass) and Refactor (aggressively refactor the code to improve code design).

A couple of advantages of TDD are that by write the tests first you've got proof they can fail (otherwise you could have accidentally written a test which will ALWAYS pass) and you're writing the tests agnostic of how you're writing the code (so you're less likely to write tests that contain the same logic as the production code - which is pointless).