When practicing Test Driven Development, we use the 3 steps Red Green Refactor. The first step is meant to check the test itself, to make sure that it will actually fail when it's supposed to. I have found quite a few instances where tests have been written without this critical first step. The reason behind this step is to make sure we can trust the test itself, and if we can't be sure it fails when it should, then we probably shouldn't be including the test in our automation. If it passes when it should fail, then it is giving us false information and that is worse than no information. We stick to the recommended approach:
1. Write a test, it fails (no code to test yet) (Red)
2. Write just enough code to make the test pass (Green)
3. Refactor the code (AND the test code), keeping the test passing
3A. (This is where any simple logic would be written)
When satisfied, start over with a new test.
I find that step 3A is where we lose a lot of folks. Simple logic pretty much includes a calculation or deterministic algorithm. If there is any kind of branch statement - IF, SWITCH, etc. these should all be coded only as a result of new tests.
If we stay with this approach, we will have valuable information about the state of our code and a mechanism to make sure the code actually does what we wanted it to do.