3 ms·

How do you know the contracts are being followed?

• _0ffh 2y ago
  Assertions?
  • dataflow 2y ago
    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.
    • _0ffh 2y ago
      Of 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 ago
          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 2y ago
            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 2y ago
              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.
      • rocqua 2y ago
        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.
        • _0ffh 2y ago
          Hey, I'm arguing in favour of contracts and assertions here... XD 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.
    • rocqua 2y ago
      Tests have the same effect right?
    • deleted 2y ago
      [deleted]
• rocqua 2y ago
  Either through assertions, through fuzz testing, or by formal verification.
  • dclowd9901 2y ago
    Maybe I’m confused on the jargon here, but aren’t unit tests assertions?
    • rocqua 2y ago
      No, 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.