Moq, according to its GitHub page, is “The most popular and friendly mocking framework for .NET”. Mocking frameworks allow you to create a ‘fake’ version of a dependency (typically an interface, or abstract class). With this fake, you can then instruct the methods return values, or invoke behaviour. Alternatively you can assert the methods were called, with a certain set...
More often than not, I want to assert that my dependency has been called with a parameter that matches more than one condition. Let’s say we have a method that calls ICustomerService.Add method. We want to assert the Add method was called with a Customer that matches a few conditions. The way we’d typically achieve this is by doing something like this: var fake = A.Fake<ICustomerService>();...
When testing a simple express app / api I like to use supertest. This can feel like integration testing, and to an extent it is. But we can stub things out with sinon, and tidy up our tests. Let’s look at an example. Suppose we have a simple API with the following router: var express = require('express'), app = express(); var router = express.Router(); app.use('/', require('./router'));...
Just wanted to do a quick post on unit test method naming, in particular with .net projects; Most test suites I come across are title cased: public void LikeThis() This annoys me. I find long method names hard to read, and easy to miss detail Example: public void DoesNotReImplementAdditionalInterfaceAlreadyImplementedByInterceptedClass() is not a readable as: public void...
Recently, I was writing a module that took a callback, and needed to write a test, asserting on an exception. Here’s how to do it: it('throws error if myParam is less than 10', function(done) { var fn = function(){ myModule.doSomething(8, function(err) { if (err) throw err }); } assert.throws( function() { fn() }, /Value is less than 10/ ) done(); }); Assuming our module looks something like...