If you are familiar with hamcrest and JUnit the time will come when you have
the need to create your own matchers.
Creating your own matcher can be as simple as useful. One reason for
creating your own matcher could be that your object is not a default object
like a String or a Collection. And if you would like to get a more readable
version of the assert for the next developer who has to read your
test. Let’s make an example. If you have an object with two methods;
“getName” and “getNumber” and you would like to check whether the resulting object
has the correct values.
In my opinion the best way to verify this is to create two matchers and
combine them. Before we can combine these two matchers let’s see how to
create them. Continue reading
Do you program or do you already TDD? 🙂
If you prefer to do TDD you will love the eclipse plug-in called MoreUnit. It is as simple as powerful. All it does is executing tests from corresponding productive class and makes it very simple to change between them.
Just press Ctrl-J (like Jump) to jump from test to implementing class and the other way. Or press Ctrl-R (like Run) to run the test regardless if you are in the test or the implementation class. Continue reading
Updated: new version here!
I have compiled two cheat sheets about clean code (the ones mentioned in my post about Code Quality!).
The first covers clean code – code that is easy readable and keeps changeable. The second is about Test Driven Development. Both cheat sheets list principles, patterns, practices and smells.
You can download them here – Clean Code Cheat Sheet V1.3, Clean TDD Cheat Sheet V1.2.
Take a look!
I’d like to read your feedback in the comments section…
(just an unreadable preview 🙂 – click on link in text above)
To continue my series on Mocking Katas (see Mocking Kata – Instrument Processor for the last Kata), I’ll show you a very simple Kata that I normally use in my Test Driven Development training courses to introduce mocks (created manually or dynamically with the use of a mocking framework): the CharacterCopier.
We use Coding Katas in Coding Dojos to improve our programming skills. This includes skills in software design, refactoring, Test Driven Development, Mocking, tool usage and a lot of other tiny stuff.
However, I found only a few Katas, especially Katas including the need for mocks (see for example http://codingkata.org/). Most Katas are very algorithmic, which is good for learning TDD. But its bad for learning how to use mocks.
Therefore, I started to invent my own Mocking Katas. I use these in my training courses on Test Driven Development.
The Model View View-Model pattern gained a lot of momentum lately. It allows to reduce the code in the code behind class of a form or user control to a minimum. Therefore, unit testability is improved dramatically compared to other view patterns like MVC/MVP.
However, when I design software, I follow (amongst others) the principles of SOLID (link).
The first principle in SOLID is the Single Responsibility Prinicple (SRP) that states that “A class should have one, and only one, reason to change.” (link)
And here start my concerns about MVVM.
NMock2 is a library for assisting test driven development of .NET code by providing a dynamic mock object creation framework.
In this article, I’m going to show you the basics of the new stub feature in NMock2. Note that this feature is currently only available on the development trunk in the subversion repository at https://nmock2.svn.sourceforge.net/svnroot/nmock2/trunk. Therefore, the features discussed here may change for the next official release.
Stubs can be used in scenarios where you have to test an instance of a class (let’s call this object testee) and this testee makes calls to another object (dependency) but you simply do not care what the testee calls on the dependency because it is not relevant for your test case.
Stubs will simply ignore any calls to it and if the call has a return value then the stub provides a default value.
Andrew Kazyrevich published a post containing timing comparisons of Moq, Rhino Mocks, Isolator and NMock2.
And NMock2 – although still lacking some features – is very fast compared to the competitors. Woohoo!
I’m curious how the newly introduced features (mock classes, non-strict and recursive mocks) will change in this setup. I’ll check that out as soon as I find some time :-O
If you want to check the new features (alpha!) yourself then here is the svn URL: https://nmock2.svn.sourceforge.net/svnroot/nmock2/branches/nonstrictmocks
For those of you interested in TDD:
I’m speaking at the conference SET (Software Engineering Today) in Schlieren (Zurich) on Tuesday May 5th.
I’ll show the basics of the TDD cycle, benefits and pitfalls, and how you get started.
Link to SET 2009: SET 2009
Link to my session (german): TDD
Looking forward to some interesting discussions…
The first release candidate of version 2.0 of NMock2 – a .net dynamic mocking framework – is published.
Check it out at: sourceforge.net
You can provide feedback at: NMock2 forum
- virtual/abstract classes can now be mocked (with default or transparent mock style)
- Stack traces of exceptions thrown in event handlers of events fired on mocks are preserved
- Source is now on Visual Studio 2008 (target framework is still .net 2.0)
- Events of inherited interfaces can now be fired on mocks
- internal interfaces of signed assemblies can now be mocked (contribution of Matthias Weibel)
- Swallowed exceptions are rethrown in VerifyAllExpectationsHaveBeenMet