Reply to thread

Message: [QUOTE="Phlip, post: 3855433"] You write the simplest code which can pass the test, modulo a couple sanity checks. In a greenfield project, you should Fake-it-till-you-make. When you write a new test case, it should use the target method in a different way. This effect will force out the fake responses, because the simplest code becomes the one that processes the result correctly. Consider one test on a linear function. You put in X1 and get back Y1. The next test puts in X2 and gets back Y2. The simplest code to pass the test is no longer 'if input == X1', it's the actual linear function describing a line through X1,Y1 and X2, Y2. Writing the test that varies the input correctly takes some work. The relation between X1 and X2 might not be so obvious! The "Fake-it" practice forces you to think about these relations. However, in a project with legacy code (such as Ogre3d, HTML, etc.), tests are more expensive. So a test on X1 might be simple and X2 much harder. In those cases, you just write the correct implementation and keep going. Your excuse is you are not designing Ogre3d or HTML, so triangulation and "Fake-it" are less important. Hence, you only need test saturation if your project actual needs QA, and some don't. TDD is still doing its most important job - preventing debugging. [/QUOTE]