I don’t have particular experience here with golang, but in other languages the biggest reason for this is mocking and stubbing everything.
Junior or intermediate developers start writing code. Most functions manipulate internal state instead of acting cleanly on inputs/outputs. Writing tests for this style of code is hard, so developers reach for the nearest mocking library. Now, instead of testing that given inputs produce given outputs, tests are written in a way that effectively they only verify that functions are currently implemented the way they are currently implemented.
These style of tests literally have negative value (NB, not all mocking is bad, but these type of tests are). Delete them when you find them.
Testing should help you accomplish two things: find bugs and allow confident refactoring. These do neither.
They don’t help you find bugs because they don’t look for bugs. They look for “the code is currently implemented in a certain way”. And this of course means if you implement the same logic a different way, they will fail.
Negative value. Delete them, and whenever possible rewrite modules that are designed such that they need to be “tested” in this manner.
Testing should help you accomplish two things: find bugs and allow confident refactoring. These do neither.
Technically the primary goal of testing is to document for other developers (and future you) how something is intended to be used. The documentation being self-verifying most definitely helps with refactoring and may discover bugs, but those are largely incidental.
Comments
I don’t have particular experience here with golang, but in other languages the biggest reason for this is mocking and stubbing everything.
Junior or intermediate developers start writing code. Most functions manipulate internal state instead of acting cleanly on inputs/outputs. Writing tests for this style of code is hard, so developers reach for the nearest mocking library. Now, instead of testing that given inputs produce given outputs, tests are written in a way that effectively they only verify that functions are currently implemented the way they are currently implemented.
These style of tests literally have negative value (NB, not all mocking is bad, but these type of tests are). Delete them when you find them.
Testing should help you accomplish two things: find bugs and allow confident refactoring. These do neither.
They don’t help you find bugs because they don’t look for bugs. They look for “the code is currently implemented in a certain way”. And this of course means if you implement the same logic a different way, they will fail.
Negative value. Delete them, and whenever possible rewrite modules that are designed such that they need to be “tested” in this manner.
Technically the primary goal of testing is to document for other developers (and future you) how something is intended to be used. The documentation being self-verifying most definitely helps with refactoring and may discover bugs, but those are largely incidental.