Who needs a mock framework?
In Groovy, you can create mocks & stubs using native language features, so you can forget about learning a mock framework.
class Author {
def getName() {
return 'Josh Brown'
}
def isFamous() {
return false
}
}
Let’s stub the isFamous method:
def author = [isFamous: {true}] as Author
assert 'Josh Brown' == author.getName()
assert author.isFamous()
(If you haven’t already, stick the above code in your groovyConsole, run it, and play around with it.)
When mocking and stubbing are so easy to do with the language itself, using a mock framework is overkill.
[Update: Bob Martin recently wrote an excellent post about Manual Mocking.]
Inside the Machine 
Groovy does make it very simple to stub out functions. But how can you verify interactions?
For example, using Mockito’s testspy functionality on some Java classes:
interface EmailService {
void sendMail(String subject, String body);
}
class ServiceConsumer {
// Method to be tested
void doSomething() {
…
emailService.sendMail(“subject”, “body”);
…
}
}
@Test
void shouldSendEmail() {
consumerService.doSomething();
// Check the emailService collaborator was called with the correct arguments.
verify(emailService).sendMail(“subject”, “body”);
}
IMO mocking with gmock is clearly superior
to groovy’s onbord-mocking.
I’ve heard GMock is good, looking to try either GMock or Spock, any recommendations?
I think the point of Josh’s post is to utilize Groovy rather than a framework when your testing is simple enough to do so. Wanting to test multiple services interacting with one another is probably a good pressure point to start considering a framework.
The temptation coming from Java is to rely on frameworks to do everything for you and never really think much for yourself. With Groovy, you’ve a much more powerful language that lets you do a lot of things Java couldn’t do. If a couple lines of code can replace your need for an entire framework, it’s possible that the framework isn’t worth using, even if it does look nice on a resume.
Well said Marc. Josh definitely has a point.
Its easy to forget that you can just use ducks.. I mean maps.
Mock Frameworks are important when you want to verify that the artifact that you are testing is exercising certain code paths of a mocked object. Its good to know when you ought to use a mock vs a map.
@Richard Paul
Actually, you can also verify interactions with plain Groovy. Using your example:
@Test void shouldSendEmail() { def wasCalled = false def emailService = [sendMail: {subject, body -> wasCalled = true assert "subject" == subject assert "body" == body }] as EmailService consumerService.emailService = emailService consumerService.doSomething() assert wasCalled }Groovy’s built-in mocking is definitely usable but has some limitations. One is that it only works if the class under test is written in Groovy. With GMock and Spock, you can also test Java classes.
@Peter – all of the code here works if the class under test is written in Java – I tested it. Can you give an example of when the class under test cannot be written in Java?
http://twitter.com/unclebobmartin/status/5228631143 “Mockito is very pleasant as java mocking tools go. But it’s still usually easier to write a simple stub by hand.” – Uncle Bob Martin
thanks, your post helped me ! Keep on blogging ! :)