mocks

Mocking React/Apollo Data Tables for UI Development

Recently, I was tasked with creating a new screen containing a table of data for a project using React and Apollo. In the past, we would typically start by defining the database table, other access layers in between that and a GraphQL query schema, and finally the query on the front end using Apollo. This has been quite tedious, and often, we ended up tweaking the schema many times until we ended up with precisely what the front-end UI needed. Read more on Mocking React/Apollo Data Tables for UI Development…

Mocking in JavaScript Unit Tests Using Sinon.JS

Lately, I’ve been using Sinon.JS for mocking in my unit tests. By using mocks for dependencies inside functions, I can write unit tests that are resilient to a changing codebase. Functions with mocks can also be developed without worrying about the chain of dependencies that could affect the logic inside the functions. Read more on Mocking in JavaScript Unit Tests Using Sinon.JS…

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());
};

Read more on Working with Custom Return Values in GoogleMock…

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…

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.

Read more on Easier Mock Construction in .NET…