Hi Lari, thanks for your comment. Now that I'm understanding better how the mock framework bundled with Grails works (or actually, how it doesn't work), I have to agree with you. I shouldn't be mocking Object nor any other object using this framework, since it is too dangerous.
The least this approach should do is undo all modifications after each test is run, which doesn't seem to happen.
Also, from a Mock's perspective, in languages like Groovy, we shouldn't be required to specify a class for creating a mock. Rspec-mock won't require this, for an example, nor do Sinon.js. I just used it because as I was reading the documentation on Testing for Grails 2, the mockFor was mentioned for dealing with the case I needed to deal with.
But after dealing with those problems and thinking a bit more about the problem, it turns out that in lots of situation, a stub would suffice and instead of using mockFor(class, true), a single map with closures as values when a method is needed would be a much simpler way to implement those.
But if you need to be sure about the call order and frequency, you still need some framework for doing it. I guess some builder would be the right way of implementing such framework without messing out with any class' metaClass. A promising approach is the one used by GSpec:
It would be awesome to have something like this integrated to Grails in some way that we could use the other MixIn's. This should be the standard approach for mock in Grails in my opinion. I'm not talking about the syntax itself. Even preferring the BDD style of writing specs, the builder could be used to write in both asserts and specs style.