Did you had the problem your mock must act like a bean? And you could not create the object with the real implementation? And the interface was too large, so you would not create a innerclass for the test? I had this problem too. I solved it with the answer in mockito.
This is a small summarization what the differences are between the different variations creating mocks with mockito.
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.
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.
Test Driven Development (TDD) is often reduced to the three phases
There is nothing wrong about these three steps. But there is more involved in test-driving your development.
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!
The first post of this series gave a quick overview over the event tester usage, the last post gave a deep dive into some part of the event tester code. When talking about line numbers or certain code expression I’m always referring to the code provided in the last post.
When talking about the expression tree construction in the last post the last thing we got into was the build up of the if/then/else expression. After building up the if/then/else expression we need to build the expression code which calls the if/then/else expression by passing in the parameter array which we built up with the GetParameterExpressionsFor method.
In my last post I gave a quick overview over the event tester usage and how you could benefit from such a component. In this post I want to show you the source code of my event tester implementation and give you a short dive into the expression tree magic that is happening behind the scenes. This time I show you first not only portions of the code but the whole code in advance annotated with line numbers. My explanations will point to line numbers in the code below.
I always wanted to get my hands dirty with a little expression tree magic but never had the time to do so. When test driving code of a component you are currently working on you might feel in the middle of the “Do a little change, let it fail, make it green” process that your component needs an event which is publicly visible and can be subscribed by clients. But how would you test that the event is fired on your component’s interface? I’ll show you how this is normally achieved and how an event tester could simplify the process.
In my first post (link) I’ve explained what StyleCop is and how you can start with your own StyleCop rules. We will now dig a little bit deeper into the jungle of StyleCop….
Lately, I asked myself why I like Scrum most. I’m a big fan of Scrum because of a lot of things. So I asked myself: “What is the root cause of all these”.
I tracked it down to two main things:
I’ll come back to that later.
I’m also a big fan of Test Driven Development. Guess what, I performed a root cause analysis on TDD, too. And once again:
After that, I asked myself: “Are there other things I like with these root causes?”.
Yes there are:
So it seems, I’m addicted to the Focus-Feedback drug :-O