3 ms·

It seems like a lot of the logic behind "tests shouldn't break due to a refactor" presumes that tests only test the publicly facing endpoints into the code. The

It seems like a lot of the logic behind "tests shouldn't break due to a refactor" presumes that tests only test the publicly facing endpoints into the code. The tests that do the best job of reassuring me are tests against code in utility functions and the like. It's hardly a refactor if none of that changes.

atom_arranger 8y ago
If you have a user facing component that uses utility functions, let's say a component that shows a table with a sum (that uses a utility function). Then refactoring your sum function should not break your tests of the table component. I'm not saying you shouldn't test your sum function using unit tests, but ultimately users don't care so much about the sum function, they care that they have a table, and it should show a sum, and so that functionality should be tested.
- kurtisc 8y ago
  Users care if the table is broken because it's taking too long to find the bug from endpoint-only tests
  - Aeolun 8y ago
    Your endpoint test would presumably make sure the table is working.
    - kurtisc 8y ago
      That's what I'm saying. But it only tells you that it is broken, not why. Users don't use tests, tests are for the developers.
Double_a_92 8y ago
However if you test too much of your "internal" code, you just end up cementing the currently implemented logic. I often see tests that are basically checking if the code didn't change. I.e. checking if function calls (on injected (mock) objects) have been done in the exact specific order, instead of checking for some correct end result.