I worked somewhere that had very complicated price calculations. The complexity came from all sorts of options like pricing schemes, taxes, etc. Many were optio

I worked somewhere that had very complicated price calculations. The complexity came from all sorts of options like pricing schemes, taxes, etc. Many were optional and there were all sorts of interdependencies. It returned an object with lots of pricing details. It really, really sucked to change or debug and there were 0 tests. I added some tests like you described. Some known price inputs and configuration options and the observed return value from a presumed good state. It didn't verify anything was correct, but it did catch “drift.” The expected object would be updated when changing the calculations, if the difference conformed to expectations based off the changes. I got some pushback because the tests werent testing correctness but it was trivial to implement and it did catch cases where we changed something and something else that should have been unrelated changed as well. A shit test for even shittier code I guess.