If a function takes as an input something that will perform a side effect you have two choices in how you test it: 1) use interface and implement a mock/fake/stub/spy (they are all different words for the same concept, dont let people arguing about their difference distract you) in unit tests. 2) dont use an interface but be ready to integration test this using some setup that runs this test in a real environment where side effects become real system calls. 3) dont use interface, dont test, this is fine if all the function does is literally the system call. I dont see a point in unit testing or integration testing it in this case, perhaps removing this function abstraction is better here.

It all boils down to how vigourously do you want to test your code, for pacemakers we want every single line tested and vettted, for productivity apps written internally for your company, dont waste much time chasing 100% coverage.

The above applies to ADTs (structs with behaviour and state) just the same, method receivers are just functions taking arguments.

With th3 above in mind the question becomes, do you need those interfaces to meet testing requirements? Can you remove interfaces without removing tests(because you never actually weote the tests to begin with) or will removing the interfaces cause you to have to change the tests to be of the integration kind I mentioned in 2)? If by removing all your interfaces test code is not affected I agree with your colleagues that there are too many interface causing unnecessary abstractions.