TDD how to handle a change in a mocked object

后端 未结 4 1186
孤街浪徒
孤街浪徒 2021-02-13 02:32

In writing unit tests, for each object that the unit interacts with, I am taking these steps (stolen from my understanding of JBrains\' Integration Tests are a Scam):

4条回答
  •  野性不改
    2021-02-13 03:00

    Revised: This is a tradeoff. Ease of testing by isolating an object from its environment vs Confidence that it all works when all the pieces come together.

    1. Aim for stable roles: Think in terms of client-oriented roles (rather than a bunch of methods). I've found roles (written in terms of client's needs / client-first / outside-in) are less volatile. Check if the role is a leaky abstraction betraying implementation details. Also watch for roles that are change-magnets (and come up with a mitigation plan).
    2. If you have to make changes, see if you can 'lean on the compiler'. Things like changing a method signature will be flagged up nicely by the compiler. So use it.
    3. If the compiler cannot help you in spotting the changes, be more diligent that usual to see if you haven't missed a spot (client usage).
    4. Finally you fall back on acceptance tests to catch such issues - ensure that Object A and Collaborators B,C,D are playing by the same assumptions (protocol). If something manages to escape your dragnet, chances are high that at least one test should spot it.

提交回复
热议问题