| This is really interesting. I am someone who does not see the value in over 60% of tests. Even less so if they are written by the person who wrote the code. Huge fragile technical debt. Many times you see developers mocking or stubbing functionality in such a way that the code behaves identically to the production code only through a different mechanism. So you have at least duplicated work. The best kind of test is your error logs and your user feedback. I am also someone who, at interview, is a proponent of TDD - but in reality, and after landing the job - has never used it nor worked anywhere that has used it where they say they do. With that in mind. How the fuck do you manage change requests with TDD. Riddle me this… given: We change the code behavior, and now our test fails! But the failure isn't because we introduced a bug, it's because we changed our mind. The new message is now the correct behavior of greet(), and so the test is now incorrect and needs to be updated. Time spent "fixing" the test is pure overhead.
So you have two test specs, since if I am new to a TDD codebase I won’t know which tests, if any, I should change for a given behaviour change. The old one that returns “Hello Brandon” and now a new one written by me, “Hello Brandon welcome to blah”. Now I do the TDD loops. Code fails, I write my code, new test passes but now old test fails? What do I do? I should never change my tests to satisfy the needs of my code.Do a whole back and forth with whomever comes up with the specs? Or Edit my code so on the second invocation it presents the correct message, assuming tests are run in a consistent and deterministic manner this would work. In this instance it would be pretty clear there is a wrong specification so I could go back and ask someone for clarity. But what if it is not clear. What if it is some intricate or subtle behaviour change where you can’t use your intuition to figure out what is a correct test or not. How do you even know if the tests that you have written correctly describe the desired behaviour? Pass them by the decision makers who are most likely non technical? The only thing that important is how your end users interact with your services and what is a dealbreaker to them. Everything else is a nice to have. These can not be tested in any way other than having your application in their hands. This mo has served me very well in my career so far. |