This is a small summarization what the differences are between the different variations creating mocks with mockito.

Null values (default)

Per default, after creating a mock, every method will return null. Just create your mock with:

Sample sample = Mockito.mock(ISample.class);

I think, this is very useful and straight forward. (And based by mockito developers idea, to create very fast a mock for testing). Sometimes it is very difficult to determine an error which was produced through such a null value. For this case it is very practicable to tell mockito, returning SmartNullValues.

Agile, Java, Test Driven Development, Testing Agile, Java, Mockito, TDD, Test Driven Development, Testing

These are the slides and comments of a presentation I held for bbv Software services AG.

The presentation is about how we get quality into our code.

Buzzwords: Fokus, frequent measurements, strong team, clean code, pair programming, test driven development, acceptance tests, continuous integration, collective code ownership, team learning.

Urs Enzler
Senior Software Architect
bbv Software Services AG

urs.enzler _at_ bbv.ch  (replace _at_ with @)
www.bbv.ch

Copyright © 2010 bbv Software Services AG

How to get quality into source code – that’s the question I’ll try to answer in this document.

You’ll see what we do at bbv Software Services to get code that is built with inherent quality and why it is important to think about quality throughout the whole development process.

Agile, Presentation, Test Driven Development Acceptance Tests, Agile, Collective Code Ownership, Continuous Integration, Development, Pair Programming, Presentation, Refactoring, scrum, TDD, Team Learning, Test Driven Development, Testing, Unit Test

I must say I’m really a huge fan of Moq. Moq is steady growing and the developer community is quite impressive in inventing new features and extensions. I recently ran over a nice feature suggestion placed in a private branch from moq. The branch belongs to Brian J. Cardiff. I suggest you check also his blog out! The feature brain suggested is an extension method which allows to do sequential setups. The sequential setup allows to specify in a fluent way for example different return types on a mock for each call. Let’s have an example!

.NET, Testing Mocking, Moq, TDD, Testing, UnitTesting

How to find a concurrency bug – this was the question I asked myself some time ago.
It is always very hard to find a concurrency bug. Mostly you have no idea when it happens or if it is really a concurrency issue or some nasty bit of code. If it is a concurrency issue the question is if the bug is in your code or in a supplied library? Will the problem happen only on multicore processors or on any machine? Besides the technical problem the customer is eager to get a solution and management… we’ll i guess you know the story.
I won’t be able to tell you everything there is to know about concurrency testing – but I’ll show you a way that worked for me in most cases.

Java, Methodology, Testing Concurrency, Java, test, Test Driven Development, Testing

A few weeks ago, I started using Mockito. Mockito is a mocking framework for Java.

What mockito is able to do:
- mocking interfaces and abstract classes
- mocking concrete classes
- spy real objects

(http://code.google.com/p/mockito)

I liked mockito so much that I decided to present it to you…

Java, Testing Java, mocking framework, Mockito, Testing

Often I get asked: Why should I write a test. What should I answer?

My preferred answer is: It’s an insurance to you.
At the time you have tests for your code, somebody else can do modifications on your code and you are sure it still does what it should. Otherwise your test will fail. (Well some people think: Why should somebody else modify my code? That’s impossible, this code is too complex, as it can be modified by somebody else… But this is another story.)

I also like the counterquestion: How can you assure me this code is working?

Testing Testing