I have inherited some code at work and have decided to use the project as an excuse to make my foray into TDD. I have made some progress by writing a test, then making sure the code passes the test. After that I move on to the next test. I am impressed at how this process easily catches when I break something unintentionally.
However, I read about people writing all of their tests first and then writing the code to fit the tests after. Is this the preferred method? Is writing tests then writing code a valid way of doing things?
Also, one more thing. I had a method that used time(). But that's not testable because if I call time in the test case, it will be different than when it is called within the method; making a correct comparison impossible. so I moved the time() call outside of the method and passed the result as an argument so I could easily compare my test with the output. Is this kind of change helping me by making my code more testable or is there a better way to write the test without modifying the method. I guess I want to know is, how much of my code should I be changing to accommodate tests?
In reply to Test Driven Development Workflow by actualize
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |