[scaryspooky]

> 2. Tests: "With increasing complexity your codebase will become much harder to maintain and control — tests will do it for you." Good intentions here but be careful. Tests can cause people not wanting to refactor/fix because now they have to fix the structure of the tests. Refactor means more than changing the implementation of functions.

Isn't the entire point of tests that you can refactor the code under test without changing the tests themselves? Otherwise how do you ensure that you have not introduced bugs in the code by doing your refactor because you've changed the thing that tested the code in the first place.

A refactor of the tests should be done independently of the code under test.

[anon84598]

I agree and I think this is why OP said to be careful -- there are so many engineers out there who do not separate the ideas of code and functionality. When these people write unit tests, they are essentially just checking that the unit behaves exactly as it currently does (white-box style), instead of checking that the unit behaves as desired (black-box style). Every subsequent change to the codebase requires a corresponding change to the tests, even if the external behavior of the unit remains the same.

[DogLover_]

Yes, ideally. Usually though you have to make changes because something is not working as it should or you found a better way. If you never change the interface the code often times rots. Most of the time we don’t make the correct design decisions from the start. We learn from previous understanding and that might require to do things over.