4 ms·
You don't even have to think that far ahead - consider some code you wrote in week 1, that was then modified by a colleague in week 2, now you return to the cod
by hacker_9 9y ago
You don't even have to think that far ahead - consider some code you wrote in week 1, that was then modified by a colleague in week 2, now you return to the code in week 3 - what does the code do? Any mental model you had at week 1 is now irrelevant as the code has changed in unknown ways. What is the current intent of the code? Do you feel safe modifying it, despite the fact you no longer know how to manually test all the end points? You only have to miss one to have clients and managers breathing down your neck when the blame game is played as to who broke the app in production.
- feikname 9y ago> Any mental model you had at week 1 is now irrelevant as the code has changed in unknown ways. Isn't that what good git commit messages are for though? (Or any other source code versioning tool.) I'm not saying tests aren't useful, but often times I find reading a file diff history is way more useful to understanding it than its tests. IMO, tests should be there only to provide some level of feeling safe modifying files, as you can easily know if you messed up something.
- hacker_9 9y agoIt'll definitely show you the changes, but how far back do you start from? and how many files do you do this for? In addition, it doesn't show you how the dataflow changed; you need to model that in your head still. Tests would also do this for you, but without the mental burden of brain compiling. It's nice to be able to set some breakpoints in code, then start a quick debugging session with the relevant test and see the data flow through the code - you can understand any function usually within 5 minutes.
- nightski 9y agoWhat do I do? Review the changes in git. Am I the only one that doesn't have much faith in unit tests preventing a regression even on a well covered project?