Roy today proposed an Abstract Expectatations and Isolation Syntax.
It sounds pretty interesting but I'm worried it might gloss over some of the valuable differentiating factors among mock object frameworks.
Union or Intersection
Ultimately its success will depend on whether AEIS takes a union or intersection approach to its API design.
Union: AEIS tries to support everything all of the frameworks can do. The downside is that the user loses the built-in constraints that indicate when a framework cannot do something in particular. It's unclear what would happen if one attempted to use unsupported constructs within a test.
Intersection: AEIS only supports common features among all frameworks. The downside is that the user can no longer access certain fancy/more powerful capabilities only offered by one framework or another.
With and end-user facing API like AEIS, I am somewhat concerned about limiting the ability of mock object framework providers to innovate with respect to syntax and expressive power.
However... Roy may yet be able to pull this off!
It's hard to sell an abstract product
Differentiation in an abstract API is difficult because the abstraction limits the range of capabilities that can be exposed.
For this reason, I tend to pursue abstraction behind the scenes rather than at the surface. Users may not get as much front-end unification but instead they receive an effective set of concrete APIs that nevertheless take advantage of unification of back-end services.
For example, all mock object frameworks would benefit from common execution and reporting hooks. Likewise, they may benefit from a common constraint framework. The expectation syntax can be somewhat unified among record/playback tools, but eventually we reach a point where abstraction produces diminishing returns and each framework will need to go its own way.
So I believe that for AEIS to take off, it will need to know when to step out of the way and allow the individual frameworks to express their concrete nature in the fullest.