5 ms·

Seems like that would make it less of an integration test

• jmholla 6y ago
  They said it was for unit tests.
• Heliosmaster 6y ago
  they mention this was a unit test, for which stubbing the hashing function would have been totally fine
• treeman79 6y ago
  This! Take over a project with thousands of integration tests. I trust none of them. Why? Because anything hard to test has been mocked to oblivion. I have api endpoints that have massive complicated integration tests. I eventually just got source for every project in company and checked to see what they actually did with API.
  • thaumasiotes 6y ago
    In this case, I think mocking is the right thing to do. You want to know that you can handle the case where two hashes collide. But for this purpose, you don't care at all how the hashes were generated. If the website changes its URI hash algorithm, the "honest" test that just supplies two URIs that happened to collide under the earlier algorithm will suddenly become worthless. The mocked test will continue doing exactly what you always wanted it to do -- exercise the "what if the hashes collide?" case in your code.
    • cle 6y ago
      You still have to reason through “what if it collides with the real hash function?” How do you know it will behave the same if you don’t test it? (I can sympathize with both approaches and don’t think either one is better.)
  • jskdvsksnb 6y ago
    I have the inverse - I started at a place that has hundreds integration tests that require a database, k8s, the whole shebang. No mocking anywhere. Tests take an hour to run, are extremely fragile and flakey. Getting your local dev machine set up to run even a subset of the tests is a half day ordeal, and it can change periodically. If you have external dependencies that don't version their APIs well it may be inevitable that you need to run tests against them. But for developer productivity you should have a fast/non-flakey path to run local unit tests with no network dependencies. It's also great for working on a plane.
    • 978e4721a 6y ago
      Cause everyone works mostly on a planes, right...
  • njharman 6y ago
    > Because anything hard to test has been mocked to oblivion. Agree. Not an integration test. If it has mocks in it, it is not testing the INTEGRATION of/between components. Mocks are for Unit tests. Where you want to isolate testing one single UNIT from all the other crap it integrates with (which have their own unit tests) After all these unit tests run, you test the whole shebang together with integration tests.