Comments on: Run test code often http://www.codewrecks.com/blog/index.php/2008/07/11/run-test-code-often/ Wrecks of code floating in the sea of Internet By Ricci Gian Maria Thu, 09 Feb 2012 16:15:12 +0000 hourly 1 http://wordpress.org/?v=3.2 By: alkampfer http://www.codewrecks.com/blog/index.php/2008/07/11/run-test-code-often/comment-page-1/#comment-1606 alkampfer Sat, 12 Jul 2008 11:14:15 +0000 http://www.codewrecks.com/blog/index.php/2008/07/11/run-test-code-often/#comment-1606 You described the TDD way to build a software, you also pointed out a very good practice, commit often. :) . The bad thing is that seems difficult to bring this way of writing software to project manager... I often heard the horrible "We are short of time, we cannot waste time on test" Writing no test is surely not a way to speed up the project, absolutely!! :D alk. You described the TDD way to build a software, you also pointed out a very good practice, commit often. :) . The bad thing is that seems difficult to bring this way of writing software to project manager… I often heard the horrible

“We are short of time, we cannot waste time on test”

Writing no test is surely not a way to speed up the project, absolutely!! :D

alk.

]]> By: Jeremy Gray http://www.codewrecks.com/blog/index.php/2008/07/11/run-test-code-often/comment-page-1/#comment-1604 Jeremy Gray Fri, 11 Jul 2008 21:16:15 +0000 http://www.codewrecks.com/blog/index.php/2008/07/11/run-test-code-often/#comment-1604 Ouch. Typo city. "When I first tried to force myself to religiously do the following"... it often felt weird and was difficult to get used to ...", but now if I skip a step it makes me terribly uncomfortable" "4. Write the test or tests" ... "that will" _cover_ "the code I am about to add (or change). "7. Run all tests, making sure the step 6 test _now_ passes." "1_3_. svn commit." (how can you tell I inserted the final svn up, rebuild, run all tests set before the final commit ;) How can you tell that it's Friday and it is time for me to go home from work and rest up after a crazy week. :) Ouch. Typo city.

“When I first tried to force myself to religiously do the following”… it often felt weird and was difficult to get used to …”, but now if I skip a step it makes me terribly uncomfortable”

“4. Write the test or tests” … “that will” _cover_ “the code I am about to add (or change).

“7. Run all tests, making sure the step 6 test _now_ passes.”

“1_3_. svn commit.” (how can you tell I inserted the final svn up, rebuild, run all tests set before the final commit ;)

How can you tell that it’s Friday and it is time for me to go home from work and rest up after a crazy week. :)

]]> By: Jeremy Gray http://www.codewrecks.com/blog/index.php/2008/07/11/run-test-code-often/comment-page-1/#comment-1603 Jeremy Gray Fri, 11 Jul 2008 21:11:47 +0000 http://www.codewrecks.com/blog/index.php/2008/07/11/run-test-code-often/#comment-1603 When I first tried to force myself to religiously do the following, but now if I skip a step it makes me terribly uncomfortable (except in certain very specific situations where it is best to do so.): 1. svn up. 2. rebuild. 3. Run all tests, making sure they pass. 4. Write a new test or tests (or modify an existing one or ones) that will code the code I am about to add (or change). 5. Run all tests, making sure the step 4 tests fail. 6. Write the code to cover one of the failing tests. 7. Run all tests, making sure the step 6 test no passes. 8. Repeat 6 and 7 until their tests all pass. 9. Optionally go back to step 1. 10. svn up. 11. rebuild. 12. Run all tests, making sure they pass. 10. svn commit. If there is any part of that list that people fail to execute because they fail to understand it, it is around steps 4 and 5. It is critical that the tests be written and/or changed BEFORE code is changed, and that they fail. It is only by starting off with them failing that you can know for certain that your changes are what made them pass, as opposed to writing tests that pass and just going on faith that they actually cover your changes. The only time I now change steps 4 and 5 is on the infrequent occasion that I am removing known-dead but still-tested code. Every other time, I update the tests first, make them fail, and then code to make them pass. When I first tried to force myself to religiously do the following, but now if I skip a step it makes me terribly uncomfortable (except in certain very specific situations where it is best to do so.):

1. svn up.
2. rebuild.
3. Run all tests, making sure they pass.
4. Write a new test or tests (or modify an existing one or ones) that will code the code I am about to add (or change).
5. Run all tests, making sure the step 4 tests fail.
6. Write the code to cover one of the failing tests.
7. Run all tests, making sure the step 6 test no passes.
8. Repeat 6 and 7 until their tests all pass.
9. Optionally go back to step 1.
10. svn up.
11. rebuild.
12. Run all tests, making sure they pass.
10. svn commit.

If there is any part of that list that people fail to execute because they fail to understand it, it is around steps 4 and 5. It is critical that the tests be written and/or changed BEFORE code is changed, and that they fail. It is only by starting off with them failing that you can know for certain that your changes are what made them pass, as opposed to writing tests that pass and just going on faith that they actually cover your changes.

The only time I now change steps 4 and 5 is on the infrequent occasion that I am removing known-dead but still-tested code. Every other time, I update the tests first, make them fail, and then code to make them pass.

]]>