Return to Answer

Now that said, some dry boring structural code doesn't need to be wrapped up in a test of its own. Test the interesting behavior.

Now that said, there is some dry boring structural code that doesn't need to be wrapped up in a test of its own. Test the interesting behavior.

You may find some way to decompose the complex operation into multiple testable steps. If you need that to diagnose errors go for it. Don't feel like TDD demands it though. This may make diagnosing a problem go faster but it locks down implementation details. Now the 3 step complex operation has to be a 3 step complex operation. If you ever figure out how to make it a 2 step operation you'll need to come back and remove some of these tests. Removing them not only improves flexibility but speeds up the test suite without costing you coverage. But once these micro managing tests have been created they tend to stick around. Consider giving them somewhere harmless to be where they wont be run unless needed. Just find some way to get them out of the main suite of tests.

You may find some way to decompose the complex operation into multiple testable steps. If you need that to diagnose errors go for it. Don't feel like TDD demands it though. This may make diagnosing a problem go faster but it locks down implementation details. Now the 3 step complex operation has to be a 3 step complex operation. If you ever figure out how to make it a 2 step operation you'll need to come back and remove some of these tests. 

Removing them not only improves flexibility but speeds up the test suite without costing you coverage. But once these micro managing tests have been created they tend to stick around. Consider giving them somewhere harmless to be where they wont be run unless needed. Just find some way to get them out of the main suite of tests.

You may find some way to decompose the complex operation into multiple testable steps. If you need that to diagnose errors go for it. Don't feel like TDD demands it though. This may make diagnosing a problem go faster but it locks down implementation details. Now the 3 step complex operation has to be a 3 step complex operation. If you ever figure out how to make it a 2 step operation you'll need to come back and remove some of these tests.

You may find some way to decompose the complex operation into multiple testable steps. If you need that to diagnose errors go for it. Don't feel like TDD demands it though. This may make diagnosing a problem go faster but it locks down implementation details. Now the 3 step complex operation has to be a 3 step complex operation. If you ever figure out how to make it a 2 step operation you'll need to come back and remove some of these tests. Removing them not only improves flexibility but speeds up the test suite without costing you coverage. But once these micro managing tests have been created they tend to stick around. Consider giving them somewhere harmless to be where they wont be run unless needed. Just find some way to get them out of the main suite of tests.