4 ms·

I have the feeling that this is a very high theoretical ebony tower view. E.g., I have a SWC that stores and reads something, and that similarly uses another S

I have the feeling that this is a very high theoretical ebony tower view. E.g., I have a SWC that stores and reads something, and that similarly uses another SWC to do that. If I do an integration test to write and then read something, I test very explicitly at the same time that my SWC does what it specs and is expected, as well as the lower layer SWC. (And at the same time this is also then a good regression finder for when you replace the black box you maybe shouldn't know about). However, similarly I can also write more explicit tests that test the lower SWC in isolation and cover even more cases I cannot cover by just integration testing. Arguing with purview in testing, and what should be done or not, never helped me so far in my career to end up with good problem and regression finding tests, and provide well working and robust systems. The contrary, discussions and nit-picking at that level are usually a huge red flag. Nice in theory, failed in practice.

danielovichdk 3y ago
You are then testing other peoples software, which is probably not what you want. In integration testing I see no issue in using a real instance of whatever dependency but I would never assert on the inner workings of that dependency - that is within the testing scope for the people that did that dependency, not you.
- randomdata 3y ago
  > You are then testing other peoples software, which is probably not what you want. And if it is what you want, why would you clutter an unrelated application's codebase with those tests? They are tests that apply to many projects. Ideally they would go alongside the work of the third-party, but failing that, surely the are better found in a new project focused on those tests?
scott_w 3y ago
I don’t see this as theoretical at all, it’s a pragmatic requirement to not explicitly test the third party tools you depend on. I’d never personally write a test which, in its entirety, calls a function owned by a third party and checks its return value and include that in my CI process. What would I do? - Write a unit test for the code that depends on this function, including the function call. I don’t need to test the third party behaviour specifically because I’m really interested in the behaviour of the entire code under test. If the code is broken, my own code shouldn’t work either. - Wrap and inject fakes for the contracted behaviour. This is usually for things where the behaviour is non-deterministic, say because of a network call. I don’t want CI failing because a third party temporarily fails. I’ve worked under these conditions before and it's really unproductive. Yes, I write tests for failure cases (network interruptions, for example). - I may encapsulate the database in my “unit,” depending on the application. The frameworks I like to use tend to integrate error handling for the DB, so I’m relaxed about network errors here.
randomdata 3y ago
If you find yourself explicitly testing a third-party library, you are most definitely not writing an integration test by any common definition (maybe you randomly created your own?). Third-party libraries are not exposed at the integration points. If they were, what are you writing software for? The work would already done by that third-party, leaving your efforts to be entirely pointless! You may incidentally test a third-party library when you test your integrations, but that's something else entirely, as has already been discussed.

danielovichdk 3y ago

You are then testing other peoples software, which is probably not what you want. In integration testing I see no issue in using a real instance of whatever dependency but I would never assert on the inner workings of that dependency - that is within the testing scope for the people that did that dependency, not you.

randomdata 3y ago
> You are then testing other peoples software, which is probably not what you want. And if it is what you want, why would you clutter an unrelated application's codebase with those tests? They are tests that apply to many projects. Ideally they would go alongside the work of the third-party, but failing that, surely the are better found in a new project focused on those tests?

scott_w 3y ago

I don’t see this as theoretical at all, it’s a pragmatic requirement to not explicitly test the third party tools you depend on. I’d never personally write a test which, in its entirety, calls a function owned by a third party and checks its return value and include that in my CI process. What would I do? - Write a unit test for the code that depends on this function, including the function call. I don’t need to test the third party behaviour specifically because I’m really interested in the behaviour of the entire code under test. If the code is broken, my own code shouldn’t work either. - Wrap and inject fakes for the contracted behaviour. This is usually for things where the behaviour is non-deterministic, say because of a network call. I don’t want CI failing because a third party temporarily fails. I’ve worked under these conditions before and it's really unproductive. Yes, I write tests for failure cases (network interruptions, for example). - I may encapsulate the database in my “unit,” depending on the application. The frameworks I like to use tend to integrate error handling for the DB, so I’m relaxed about network errors here.

randomdata 3y ago

If you find yourself explicitly testing a third-party library, you are most definitely not writing an integration test by any common definition (maybe you randomly created your own?). Third-party libraries are not exposed at the integration points. If they were, what are you writing software for? The work would already done by that third-party, leaving your efforts to be entirely pointless! You may incidentally test a third-party library when you test your integrations, but that's something else entirely, as has already been discussed.