31–40 of 108 posts
Earlier quoted context omitted.
Assertions?
But 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.
> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.
So glad someone’s here saying it. I am absolutely dreading tomorrow morning now with the thought our manager has also read this article.
Earlier quoted context omitted.
Unit tests are a waste of time. Design by Contract + system tests are a far superior technique that take less time and find more bugs.
How do you know the contracts are being followed?
Earlier quoted context omitted.
But 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.
Of course they don't, how could they? How could anything, for that matter? (Apart from guarantees you could ensure statically, natch.)
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...
Earlier quoted context omitted.
But 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.
Of course they don't, how could they? How could anything, for that matter? (Apart from guarantees you could ensure statically, natch.)
Earlier quoted context omitted.
Of course they don't, how could they? How could anything, for that matter? (Apart from guarantees you could ensure statically, natch.)
Assertions triggering in integration tests are different from unit tests. They don't involve writing mocks. They are generally closer to the code, especially with design by contract, so they are more likely to be fixed during a refactor. They encode what you believe your code should do more directly. And they can be used as a basis for formal verification.
I even considered formal verification, if under another name.
Ed.
I think I hit a posting limit. After reading dataflow's answer to gp I think I interpreted ggp differently from both of you.
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.
Earlier quoted context omitted.
> it doesn't sit well with bizdev or project managers To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.
The second time doesn't cost as much as the first.