News for hackers. Stuff that matters.

A comment on Write tests. Not too many. Mostly integration (2017). Parent comment

Re:Write tests. Not too many. Mostly integration (2017) by efdee on Friday February 01, 2019 @06:51AM (#19053372)
In my experience, a lot of unit tests are written with mocks, expectations, and way too much knowledge of the implementation details, which leads to broken tests simply by refactoring, even if the behavior does not change at all.

If you test units in isolation, while adhering to SRP which results in many smaller units depending on eachother to do a task, then simply refactoring without changing behavior screws up a considerable portion of your tests.

As for "tests cast away fear", that is definitely true. Whether or not the lack of fear is warranted is something else, and depends heavily on the quality of the unit tests. I've seen plenty of devs confident of their change because it didn't break any unit tests, only to discover that it broke something they forgot to test.

[ Parent | on HN ]
Re:Write tests. Not too many. Mostly integration (2017) by AtlasBarfed on Friday February 01, 2019 @04:21PM (#19058755)
Most 100% code coverage unit tests break liskov substitution / interface boundaries.

But I have seen how really deep unit tests enable rapid deployment of code to prod since it produces high likelihood of correctness.

However, refactoring and the LoC bloat is also gigantic.

And we still needed integration tests, and forget about unit tests if there is a lot of network boundaries and concurrency. It might help, but it starts to fail quickly. The facades/mocks just assume too much.

If you are in java, for god's sake use Spock/groovy even if your mainline code is java.

[ Parent | on HN ]
Re:Write tests. Not too many. Mostly integration (2017) by whoisthemachine on Friday February 01, 2019 @10:06PM (#19060763)
In my experience, if you are baking in implementation details into your unit tests, they are necessarily going to be fragile. It is best to focus on input and expected output rather than the inner workings of the function under test.
[ Parent | on HN ]
Re:Write tests. Not too many. Mostly integration (2017) by inopinatus on Friday February 01, 2019 @06:55AM (#19053399)
It is analogous to moral hazard. People with insurance take greater risks, and vice versa.
[ Parent | on HN ]
Re:Write tests. Not too many. Mostly integration (2017) by chosenbreed37 on Friday February 01, 2019 @09:04AM (#19054122)
> It is analogous to moral hazard. People with insurance take greater risks, and vice versa.

Programming with guard rails :)

[ Parent | on HN ]