News for hackers. Stuff that matters.
Re:Unit Testing is Overrated (2020) by saynay on Thursday April 07, 2022 @11:14AM (#30945528)
That is one of the big benefits I have found from writing code while planning to write unit tests for it (even if you don't write all of them). You will generally avoid patterns that will require a lot of mocks to test, which generally make that code easier to refactor and reason about. If you are able to make big chunks of your code into "pure" functions, they are now really easy to test.
Re:Unit Testing is Overrated (2020) by atx42 on Thursday April 07, 2022 @02:01PM (#30948131)
Also agree.

I've seen code so mocked it was dubious that it could be testing anything, accurately at least.

Re:Unit Testing is Overrated (2020) by rectang on Thursday April 07, 2022 @11:23AM (#30945663)
A classic approach is that if you have to make some complicated API call with a bunch of arguments, you can put all the logic wrangling the arguments into a pure helper function and unit test the helper.
Re:Unit Testing is Overrated (2020) by mring33621 on Thursday April 07, 2022 @11:34AM (#30945867)
Agree.

I use strategy pattern with Java functional interfaces to avoid using magic mocking frameworks. That way, my mocks are just trivial impls of the plugin parts.

Re:Unit Testing is Overrated (2020) by 8note on Thursday April 07, 2022 @08:19PM (#30951926)
Setting up sample data is the biggest pain for mocking in my experience. But it's true however you're testing.
Re:Unit Testing is Overrated (2020) by geysersam on Thursday April 07, 2022 @02:00PM (#30948103)
How do you accomplish that? I often end up in a situation where mocks are needed (like in the article).
Re:Unit Testing is Overrated (2020) by saynay on Thursday April 07, 2022 @03:37PM (#30949389)
Often times, you will have chunks of code that are either creating input for what would go into an interface/mock, or handling the output of it. You could pull those bits, even if they are relatively simple (maybe only a few lines, and only used in that one spot), and extract those out to a pure function to sidestep the mock.

Sometimes you can't really avoid it. In those cases, I would judge how much of the effort is testing your code, and how much is testing your ability to write mocks. Unless it is a really important functionality, or something complex enough that it would be easy to get wrong, I wouldn't bother with most tests that need extensive mocking. Instead handle those later with integration / e2e tests.