Okay, the problem then is that we've got different definitions of what an interface is. For me, coming from C++ and Java, the technical definition of an interface is an abstract superclass that provides only static data members, abstract method declarations, and that indicates an is-a relationship. To quote from Java in a Nutshell: "When you define an interface, you are creating a new reference type, just as you are when you define a class." (p. 112).

What you're talking about is behavior without association to a reference type. You essentially want a list of things that an object can do with its type information stripped away. In this sense, bart's suggestion to use can seems very close to what you want, as dws's astute observation that different classes may "mean" different things by similarly named methods is only relevant insofar as you're concerned with is-a relationships and getting one particular class-specific behavior. If your Test::MockObject is the prototypical application for this idea then I think using can is fine, as the objective there is, inasmuch as I can gather from a quick perusal, to isolate the code you're testing from other dependencies. This is a great idea, and it's much better than the one-off approach I've sometimes had to use in temporarily redefining methods just to report back some placeholder information. Nonetheless, I must cling to the belief for the time being at least that "real" code going into production or publication would suffer greatly in terms of maintainability from this sort of thing. And in that sense fixing the object model is almost always going to be preferrable to warping inheritance chains.

Due to the substantial precedence for associating interfaces with reference types, I think a different term would be helpful here. It sounds like what you want is shorthand for grouping a set of methods together into a set, but one not unified by type. Maybe "possible behaviors" would suffice?