0
0

[–] boater ago  (edited ago)

They break stupidly when code changes, and people defend them saying "Oh, well, good unit tests don't do that"

They don't break stupidly if you are doing modular functional programming and write the unit test functions in the bottom of the exact same file as the functions they are written to test. This lets you keep related logic in the same place and automatically generate unit test binaries by parsing function signatures rather than creating them manually.

However, if you put your unit test functions in a different file or folder than your primary source code, then yes they will breakly stupidly whenever you need to rename things, as you will have to many more locations in which to remember to change the name.

0
0

[–] colonwq ago 

In my experience the value of unittests really shows when you need to be sure that new features/changes doesn't break stuff that already worked. At the company I am now it is immensely useful that we have proper unittests for our application. It deals a lot with processing various kinds of input and the output needs to be consistent. I very rarely have to rewrite old unittests.

0
0

[–] Xyc0 ago 

If you have the tests before you have the code you can make incremental changes and catch the errors without deploying the whole fucking system. If you never have the tests and you only have code then you always have to deploy the whole system to test. While every developer should know the build chain and the operational scenario not everyone should be setting up and deploying complex system tests. If your continuous integration/deployment does this then you are a rare gem.