Intro to Mocking with Moq

It’s easy to overlook the importance of unit testing. Writing tests can be tedious. They must be updated constantly as code is refactored, and when you have a large code base, you may have to write many tests to even come close to testing all cases. Despite this, unit testing is a necessary part of creating clean, working code. One way to make the testing process easier is through the use of mocks. Read more on Intro to Mocking with Moq…

Bye-Bye, Sinon – Hello, testdouble

UPDATE: Justin Searls, the author of testdouble.js sent me an email with some notes on this post. I’ve added some his comments below to provide some additional context.

I’ve been working in JavaScript-land for the last little while, writing lots of Node.js code. Since I practice TDD, I’m always trying to keep my eye on the best new ways to test JavaScript code. Read more on Bye-Bye, Sinon – Hello, testdouble…

4 Tips for Improving Test Quality

Test-driven development is an essential discipline for any software craftsman. Similar to how accountants use double-entry bookkeeping as a safety net, software developers can use TDD as their safety net.

If you need a refresher on TDD — and what it is and isn’t — I’d suggest my post on why Simply Writing Tests Is Not Test-Driven Development.

1. Think of Tests as a Sum of 4 Parts

When writing unit tests, it helps to think of them as 4 parts — setup, invocation, assertion, and tear down — and to consider each step as a series of questions. I start with the invocation first. Read more on 4 Tips for Improving Test Quality…

Working with Custom Return Values in GoogleMock

When working with the GoogleMock C++ mocking library, you can get pretty far using only default expectation return values or explicitly specifying expectation return values. There are some additional options that can save you a lot of effort in some circumstances though. Let’s take a look at a few of them.

Standard Values

Consider an interface and mock like the following:

class Timer {
public:
    Timer() {}
    virtual ~Timer() {}
    virtual void Start(int) = 0;
    virtual void Stop() = 0;
    virtual bool IsActive() = 0;
    virtual QString GetId() = 0;
};
 
class MockTimer: public Timer {
public:
    MOCK_METHOD1(Start, void(int));
    MOCK_METHOD0(Stop, void());
    MOCK_METHOD0(IsActive, bool());
    MOCK_METHOD0(GetId, QString());
};

Mocking in RubyMotion: OCMock, motion-stump

We have been using OCMock to assist our unit testing in a RubyMotion application for a few months now. It was on our radar from the beginning because we’ve used it in past iOS development projects, and it has served us well. It’s a well-known library, and we know it can do the job, but it does leave some room for improvement. Specifically, it feels unnecessarily verbose against the the relatively concise backdrop of MacBacon and the Ruby language.

Wouldn’t it be nice if there was a more Ruby-like mocking library? Good news — thanks to Francis Chong’s work on motion-stump, there is!

Using CMock when C is Oversensitive

CMock is an extremely useful tool that can make testing C programs nearly painless. Employing CMock is usually straightforward, but here are a few common sticking points and ways to work around them:

Comparing googlemock to Mocha

Higher-level languages are great, but every now and then I like some good old C++. So I was a bit excited when I got the chance to use C++ recently on a piece of demo software. After spending a lot of time in Ruby and Javascript (or more accurately, Coffeescript), it was both comforting and frustrating to be back in the land of pointers, memory allocation, and static types.

Since this code was meant for a demo, it was originally written to be throw-away. Moreover, since it was leveraging a large codebase which did not have any establisted testing framework – or tests of any kind – I made the decision to just get the code working and forget about writing test suites. And then, of course, the situation changed. Suddenly the code needed to be solid enough to pass off to someone else and have them run with it. In my four months at Atomic Object, I’ve already absorbed enough of Atomic’s philosophy that the thought of my code persisting in someone else’s hands without any tests was cringe-inducing. Having done nearly all of my testing in RSpec (with Mocha) and a little Jasmine, I wasn’t optimistic that I could find something that easy for C++. I wanted something that would provide straightforward mocking capabilities so I could perform true unit tests.
Read more on Comparing googlemock to Mocha…

Mocking Objects with Sinon JS

We recently started writing a mobile website using JavaScript as our framework. To test the JavaScript framework we decided to try Sinon and Jasmine .

With Sinon a mock is created from an instance of an object. Needing to create an instance of a class to make a mock becomes difficult for classes that have complex initialization.

Easier Mock Construction in .NET

We’re currently using Moq as our mocking library on an ASP.NET MVC application. Moq has been working out pretty well, but building mock objects is a little cumbersome. We’re using StructureMap heavily, which leads to frequent updates to the constructors which StructureMap relies on to compose our object graph. Moq requires you to match the arguments of your mock constructor to the parameters of the mocked class’s constructor. Every time we mock an instance of a class we have to figure out how many arguments that class’s constructor takes and pass a default value in for each. To make matters worse, when we add arguments to a constructor, we have to move from failing test to failing test, adding null arguments to the mock constructor to fix runtime errors in our NUnit SetUp.

Testing C# Code That’s Run as the Result of an Event Being Fired

Or, How to test your Presenter classes

A couple of colleagues and I recently finished up a project for a client that involved a lot of C# code. Our unit testing tools of choice were NUnit and Rhino Mocks. The NUnit choice was a pretty easy one (although there are other platforms out there), but we spent a little more time choosing a mocking library.

Our first choice was NMock, primarily because we had experience using it on previous projects and we knew it could get the job done. Before too long, though, we switched to using Rhino Mocks. The primary reason for the change (if I am remembering correctly) was because of its superior event handling capabilities, and we grew to prefer its explicit use of the record-playback-verify mocking model.

Rhino Mocks was one of the first libraries to directly support event registration and event raising by mocks (at least, it was the first we had used). This was a big advantage over having to add a SubscribeEvent() method to our view and model interfaces and having to use syntactically obscure paradigms to capture and fire the event raisers. With Rhino Mocks we could add public events directly to our interfaces and (fairly) explicitly capture the event raisers.

Atomic Spin

Atomic Object’s blog on everything we find fascinating.

mocks