3 ms·

>For starters: Integration tests will not necessarily exercise a full range of inputs for the low-level functions. For a chat system, I would think hard about h

>For starters: Integration tests will not necessarily exercise a full range of inputs for the low-level functions. For a chat system, I would think hard about how to test low-level functions with a wide range of Unicode input. I don't see any problem at all with writing integration tests that exercise a chat system with a wide range of unicode input. I'd view it as irresponsible not to, in fact.

rectang 9y ago
Low-level functions may be reused in combinations which limit what gets fed to them by higher-level tests. Perhaps there are bugs in some text processing widget, which only happen on small blocks -- and small blocks only get fed to low-level functions on disconnection from the service, which would be too costly to repeat exhaustively in integration tests. The most reliable way to address this kind of problem is to match the tests to the function. Look at what each function does, anticipate edge cases, contemplate the core purpose, then write what you believe are an appropriate number of unit tests. You can choose not to prioritize the problems which are revealed by unit testing but not integration testing, but you can't say that such problems don't exist.
- crdoconnor 9y ago
  >on disconnection from the service, which would be too costly to repeat exhaustively in integration tests. Um, disconnection from the service is the exact kind of scenario I'd want to repeat exhaustively in an integration test.
  - rectang 9y ago
    This reply doesn't address the principle that there must be issues which can be addressed using unit tests but not integration tests. Even if you take every example I give and claim "doesn't count, I'd test for that", you're just writing unit-tests-once-removed using an integration testing framework.
    - crdoconnor 9y ago
      >This reply doesn't address the principle that there must be issues which can be addressed using unit tests but not integration tests. Well, that's asking me to disprove a negative. All I can say is that I don't think that principle is true. One counter-example of a scenario that is impossible to integration test but possible to unit test would be sufficient to disprove my hypothesis, but I don't think it exists and I don't think you can provide it. >Even if you take every example I give and claim "doesn't count, I'd test for that", you're just writing unit-tests-once-removed using an integration testing framework. I'm really not. I can test disconnection scenarios in an integration test without even coupling to the language under test by running a service that intercepts network traffic. It's obviously not a "unit test once removed" if I can literally swap out the entire language under test and not have to change the test.
      - rectang 9y ago
        I already provided such an example: the disconnection. The key aspect of that theoretical example was that it would be "too costly to repeat exhaustively in integration tests". You simply wished away that trait, avoiding the issue.
        crdoconnor 9y ago
        No, I can test that.

rectang 9y ago

Low-level functions may be reused in combinations which limit what gets fed to them by higher-level tests. Perhaps there are bugs in some text processing widget, which only happen on small blocks -- and small blocks only get fed to low-level functions on disconnection from the service, which would be too costly to repeat exhaustively in integration tests. The most reliable way to address this kind of problem is to match the tests to the function. Look at what each function does, anticipate edge cases, contemplate the core purpose, then write what you believe are an appropriate number of unit tests. You can choose not to prioritize the problems which are revealed by unit testing but not integration testing, but you can't say that such problems don't exist.

crdoconnor 9y ago
>on disconnection from the service, which would be too costly to repeat exhaustively in integration tests. Um, disconnection from the service is the exact kind of scenario I'd want to repeat exhaustively in an integration test.
- rectang 9y ago
  This reply doesn't address the principle that there must be issues which can be addressed using unit tests but not integration tests. Even if you take every example I give and claim "doesn't count, I'd test for that", you're just writing unit-tests-once-removed using an integration testing framework.
  - crdoconnor 9y ago
    >This reply doesn't address the principle that there must be issues which can be addressed using unit tests but not integration tests. Well, that's asking me to disprove a negative. All I can say is that I don't think that principle is true. One counter-example of a scenario that is impossible to integration test but possible to unit test would be sufficient to disprove my hypothesis, but I don't think it exists and I don't think you can provide it. >Even if you take every example I give and claim "doesn't count, I'd test for that", you're just writing unit-tests-once-removed using an integration testing framework. I'm really not. I can test disconnection scenarios in an integration test without even coupling to the language under test by running a service that intercepts network traffic. It's obviously not a "unit test once removed" if I can literally swap out the entire language under test and not have to change the test.
    - rectang 9y ago
      I already provided such an example: the disconnection. The key aspect of that theoretical example was that it would be "too costly to repeat exhaustively in integration tests". You simply wished away that trait, avoiding the issue.
      - crdoconnor 9y ago
        No, I can test that.