Uncle Bob's three rules of test-driven development state the following:
-
You are not allowed to write any production code unless it is to make a failing unit test pass.
-
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
-
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
In real world, for example, I have a task to complete a method which requires some complex algorithms (some advanced math knowledge for example), if I apply 3 above rules, it will be like this:
-
start writing a test case => run and see it fails
-
write lines of code that just enough to make the test pass
-
refactor the code
-
then repeat this loop.
My question is: is this approach quite unrealistic and distracted in such situations? Why don't we write the first test case, then focus on finding the solution then implement it, I mean looking at the big picture, instead of writing just enough code to pass the first test case?
(I am a new with TDD)
Aucun commentaire:
Enregistrer un commentaire