I am under the impression that interaction testing (verifying mock invocations) in general should be avoided.When unit testing method postconditions should be asserted instead.However there are cases that interaction testing cannot be avoided. In these rare cases I think interaction testing is allowable.Cases where interaction testing is ok (but still do it mindfully)interaction facilitates state change (state change through a service)interaction is side-effectful (database access, network call through a service, invocation to an observer)However there seems to be a lot of argument for interaction testing. Particularly, to make sure that:invocations do happen (even for non side effectful interactions)no extra invocations happenI think these cases fall into the implementation detail category and should not be tested anymore. While these cases have a point, tests for most implementation scenarios will have these shortcomings. And I think that there should be some level of trust that no developer in the team will write code that say for example: updates an entity and saves it to the database on a query method (clear violation of LSP, CQS and principle of least astonishment).In addition, in these cases, in my opinion, the unit test tend to mirror the code under test too closely, and fail unnecessarily when the code under test changes (regardless of effect on behavior) rendering the tests too brittle therefore making them lose their value.What are your opinions on this matter?
When is interaction testing (invocation verification) while unit testing considered excessive?
design;unit testing;testing;tdd