5 ms·
> ... basically just creates a change-detector program interesting perspective - why do you think this is a bad thing? to me, it's an opportunity to verify th
by webdood90 3y ago
> ... basically just creates a change-detector program
interesting perspective - why do you think this is a bad thing?
to me, it's an opportunity to verify that the change is intended. without it, how do you know that the program does what it is supposed to do?
- whoisjuan 3y agoNo op, but I don’t think test-driven development resounds with everyone who writes code. I don’t want to write tests for everything. I just want to write the ones that matter.
- nyrikki 3y agoThat is a common misconception about TDD. TDD is _about_ writing tests that matter, but most people think it is about writing all unit tests first. If you are following TDD anywhere close to the way it is described, you will only be writing tests that relate to domain functionality first. Note how it is described here, although it is turse. https://martinfowler.com/bliki/TestDrivenDevelopment.html https://martinfowler.com/bliki/TestDrivenDevelopment.html The coverage metric as a goal writing style doesn't work for TDD, sorry you were exposed to that. You are correct that model doesn't work.
- randomdata 3y ago> The coverage metric as a goal writing style doesn't work for TDD Coverage is not a goal of TDD, but in practice you will have 100% coverage by following TDD as you would never have reason to write code that isn't covered by test. Ultimately, the purpose of coverage tools is to let you know what you might have forgotten to clean up during a refactor, to help you remove what you missed.
- randomdata 3y agoTDD or not, why would you write tests for things that don't matter? More importantly, why are you writing any code for things that don't matter?
- siliconc0w 3y agoWithout deliberate tests it can be very difficult and time consuming to parse out intended change from unwanted or incidental change.
- nyrikki 3y agoIt tightly couples domain needs with implementation details. Thinking of it as a leaky abstraction helps me. I try hard to separate domain logic tests from implementation specific tests. Your code could be loosely coupled with high cohesion, but with lots of random tests like you get when code coverage is a performance metric, you have to add a lot of complexity that only relates to an implementation.
- elicksaur 3y agoHow do you know that the tests accurately define what the code is supposed to do? Another way, if you know what the code is supposed to do, why write it down in two places?
- bbojan 3y ago> Another way, if you know what the code is supposed to do, why write it down in two places? This would be like criticizing double-entry accounting by asking "if you know what the amount is, why write it down in two places?" We write the code down in two places because that gives us advantages that far outweigh the added effort: - Once written, your test will catch regressions forever - A test is often excellent documentation on what the code does - It's now much easier to refactor the code, making it more likely that it will be refactored when needed.
- IshKebab 3y agoIt can be. E.g. consider GUI testing where people sometimes take automatic "golden" screenshots. The problem there is that if you change some minor thing that e.g. moves text by 1 pixel it will fail the test even though that's probably fine. People then get used to just blindly updating the golden images. It becomes basically "the output changed, do you want to continue anyway" which is not the most useful thing. You really want it to say "the output is wrong".