[dataflow]

> 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]

Well, 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]

System 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]

You 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.