Carlos Ble

Carlos Ble

I am a professional software developer, I solve problems.

I also teach and mentor developers to build better software.

Developing software since 2001.

Can I help you?

  • Do you need high quality tailor-made software?
  • Need training on TDD, clean code or refactoring?
  • Is it risky? do you need advise?
  • May I pair with you to write better code?

Events

Upcoming public training courses:

  1. [Online - en Español] 25 y 26 de Junio
    Test Doubles con JavaScript - Online
  2. [in English] July 7, 8 & 9
    TDD (open to the public) - Tenerife, Canary Islands
  3. [en Español] 14 y 15 Julio
    TDD (en abierto) - Gran Canaria, Canary Islands
  4. [in English] October 13, 14 & 15
    TDD (open to the public) - London, UK
  5. [en Español] 29, 30 y 31 de Octubre.
    TDD (en abierto) - Madrid, Spain

Conferences:

  1. I'll be at SocratesUK 2014
  2. I'll be at the London Test Gathering Workshops.

Mockito Vs Moq

Don't be confused, the title is just to get your attention. This is not a benchmark between Mockito and Moq. I need to  explain some differences to my teammates so that the transition between Mockito and Moq is softer for them.

Typical way to stub out a method call with mockito:

when(colaborator.method(argument1)).thenReturn(whateverIwant);

Same with Moq:

colaborator.Setup(x => x.method(argument1)).Returns(whateverIwant);

Obviously, the mockito way is nicer. I believe this is because of Java capabilities but I am not sure. I would like to dig into mockito's source code to see how is this possible. I will do it and blog about it soon. I used to think that it was because of the kind ot late binding supported by Java, but I am not sure.

Moq uses a lambda expression (anonymous method inlined) to tell the framework which method and how is expected to be called). The reason I use "x" for the object in the anonymous method is because it refers to "colaborator" itself so there is no point in adding more names.

The other important difference relates to the "virtual" keyword in C#. Methods in C# are final by default. You can't override them unless they contain the keyword "virtual" on its signature. Both, Mockito and Moq create test doubles by subclassing on runtime, overriding methods and implementing the fake behavior on them (as far as I know). So, if the method you want to stub is not virtual, Moq will throw a runtime exception. If it is not virtual but you don't specify any fake behavior on it, it will not throw exceptions, but worse, it will call the actual implementation. So you might be hiting the database in your unit tests inadvertedly. What I do, is that all my methods are virtual by default (I write "virtual" on their signature).

There will be more posts on this topic :-)

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • AnObfuscator

    I disagree, I much prefer the lambda expressions of Moq… but to each his own. ;)

    I really do hate the explicit C# virtual/override syntax. For a language so focused on syntactical sugar and eliminating unnecessary verbosity (Java, pay attention), this is a horrible inherited syntax from C++.

  • Pingback: Cleaner interaction tests « El blog de Carlos Ble

  • SumDumGai

    I agree. I don’t think it’s “obvious” at all that Mockito is way nicer. It’s a different syntax for sure but personal preference is not an objective measure.

  • Michael

    I think you shouldn’t need to stub out concrete objects but rather decouple your classes by using interfaces. After all it is the contract you should care about not the implementation. That way you don’t need to bother about making all your methods virtual. Which is a bad idea for a lot of different reasons.

  • carlosble

    A class is also an interface. When you’ve got only one implementation, there is no point in having a separate interface with only one class implementing that interface. What name do you choose for the interface in that case ISomething? The I prefix convention for interfaces in .Net is like hungarian notation, deprecated in my opinion.

  • carlosble

    When I show Moq to someone I always have to explain what is “x” because it is not intuitive. I will starting using “self” rather than “x” to see if that helps :-)

  • Michael

    A class defines functionality and most often exposes more methods and properties then a specific interface does.

    Using interfaces focuses on the contract and allows for better changeability and testability because classes don’t care about other classes but about providers of functionality they need. Who (which class) implements this functionality is not important. One usefull side-effect is that it is easy to create and supply mockups instead of the “real” functionality.

    A discussion of naming conventions seems to me off topic.