Unified Expectations
Ben & I were discussing Instinct’s “verification” API (i.e. JUnit’s Assert) the other day when he made the observation that what we were developing was the same as what we are already doing with mocking APIs. At first I wasn’t convinced, but the more I thought about it, the more it makes sense.
What we are doing with JUnit’s Assert class is making state-based assertions, and with mocking frameworks making behaviour-based assertions. So with Instinct what we intend to do is unify the state and behaviour expectations into a single unified Expectation API.
We toyed with the naming for a while, but “expectations” make more sense than “verification” or “assertion”. It also fits in better with the experimental process (i.e. driving) when doing BDD, using words such as “must” is a bit too harsh, whereas “should” implies that you don’t really have to do it. “Expect” is a much better way to say what you really mean; “expect that foo.bar() is called”. I initially wanted to call it “ensure”, as in “ensure that foo.bar() is called”. However the naming doesn’t quite roll off the tongue, and I thought it may get confused with “insure” in conversation.