6 ms·
"Write everything twice" is a great heuristic. Extreme programming and unit tests is a dumb and wasteful technique. You end up cornering yourself.
by mempko 2y ago
"Write everything twice" is a great heuristic. Extreme programming and unit tests is a dumb and wasteful technique. You end up cornering yourself.
- nkozyra 2y agoSorry, are you saying unit testing is dumb? Not that you'd be the first to say such a thing, but I've never really understood this if people find them valuable. 100% test coverage is one thing, but having some interdependent functions that do one small thing is a perfect use case for unit tests.
- mempko 2y agoUnit tests are a waste of time. Design by Contract + system tests are a far superior technique that take less time and find more bugs.
- dclowd9901 2y agoHow do you know the contracts are being followed?
- _0ffh 2y agoAssertions?
- dataflow 2y agoBut assertions only tell you you broke someone after the fact (and only if they're enabled)? They don't do anything to help prevent you from breaking them in the first place.
- _0ffh 2y agoOf course they don't, how could they? How could anything, for that matter? (Apart from guarantees you could ensure statically, natch.)
- dataflow 2y ago> Of course they don't, how could they? How could anything, for that matter? Uh, that's literally what unit tests do? They tell you if you broke any of the cases they test for, before you release your implementation to other people...
- _0ffh 2y agoWell, that's a mutual misunderstanding then. I meant quite literally neither assertions nor unit tests prevent you from breaking things. Of course they'll help you to catch those mistakes before release. I didn't think that counts as prevention, my bad. Assertions should trigger during system testing if any contracts are broken, so under your interpretation they do prevent breakage as much as units test (meaning before shipping).
- dataflow 2y agoSystem tests prevent breakage as much as unit tests? Really? How do you "system test", say, string.indexOf(string)? Could you write a system test for this example to show us what you mean and help us see how they're superior to unit tests? And how long and complicated are your system tests to catch breakages "as much as" a unit test would, for this example?
- rocqua 2y agoYou add an assertion in the indexOf method that checks the substring is indeed present at that index. Then you run your system tests where the indexOf function is called a bunch of times. The unit tests might be better at testing more edge-cases. But they are a lot of cumbersome work (not in this example, but it is a rather toy example). Unit tests are also less self-documenting than using assertions. They say what the code should do far away from the code itself. An assertion is right there in the code, it says what should be true, and unlike comments, you will be told if they become false.
- rocqua 2y agoTests have the same effect right?
- deleted 2y ago[deleted]
- rocqua 2y agoEither through assertions, through fuzz testing, or by formal verification.
- dclowd9901 2y agoMaybe I’m confused on the jargon here, but aren’t unit tests assertions?
- rocqua 2y agoNo, a unit test is a stand alone bit of code that sets up the environment, runs a bit of code (the unit under test) and checks if the code worker as expected. This does tend to use assertions. The idea of using assertions, is to put the assertions inside the 'unit under test' so they are checked every time the code is run (sometimes with a way to disable for performance). Then you can run the code normally, and don't need to write a separate bit of code, that has to set up a proper environment (usually with a lot of 'mock' objects). This style can probably test less, but still works well for 'design by contract'. You can confirm the caller stuck to any requirements of the input, and you can confirm the code stuck to any post-conditions on it's results.
- sitkack 2y agoUnit tests are only worthwhile when your internal machinery is part of the contract.
- jackcviers3 2y agoThe last comprehensive study I read indicates that they improve internal and external code quality by 76% and 88% respectively while reducing productivity some[1]. If you have papers that indicate your claim I'd be interested in reading them or in ones that refute the metastudy linked below. 1. https://doi.org/10.1016/j.infsof.2016.02.004 https://doi.org/10.1016/j.infsof.2016.02.004
- nkozyra 2y agoTDD and using unit tests are not the same thing, though. I'm very much a TDD sceptic, but believe unit tests have a place.
- dataflow 2y agoConfused, how do you ensure that a change to your implementation of some function isn't going to break clients after deployment if you don't have a unit test?
- mempko 2y agoThe client doesn't run your unit tests, but will run you contracts (because contracts deploy with you software while unit tests dont). You might have realized users of software do things the engineers don't expect, which are not covered in unit tests.
- dataflow 2y ago> The client doesn't run your unit tests That's kinda the whole point... you run them to catch bugs and fix them so your clients never see the bugs you caught in the first place. > but will run you contracts (because contracts deploy with you software while unit tests dont). So you'd prefer your contracts to blow up your bugs in your clients' faces, rather than catch bugs yourself prior to releasing the code to them?!
- mempko 2y agoYou would obviously test the software before it goes to the users. With contracts you would be able to have information from your users that make it MUCH easier to fix. Without contracts you will have a much harder time fixing the bugs. Contracts catch bugs unit tests don't.
- dataflow 2y ago> You would obviously test the software before it goes to the users That... is literally what unit tests do. Test the software before you give it to users. You seem confused what the debate is over. Nobody is arguing against contracts. They're awesome. They're just not substitutes for unit tests (or vice versa for that matter). You guys have been arguing against unit tests, which is an absurd position to take, hence this whole debate.
- gavmor 2y ago"Write everything twice" is sometimes called a "spike."[0] > A spike is a product development method originating from extreme programming that uses the simplest possible program to explore potential solutions. In my career, I have often spiked a solution, thrown it away, and then written a test to drive out a worthy implementation. 0. https://en.wikipedia.org/wiki/Spike_(software_development) https://en.wikipedia.org/wiki/Spike_(software_development)