How would one test that a piece of custom middleware is actually called from a standard HTTP event?
ie. The middleware is called from:
MyController.js
router.get('/some/endpoint', [myMiddleware()], (req, res, next) => {
// Code to do whatever here
});
The middleware itself can be defined as:
MyMiddleware.js
module.exports = () => {
// Middleware code in here
}
My quest is to check that the middleware is called once from my unit test, but I cannot find documentation around this.
MyTest.test.js
it('Should return whatever from GET call', () => {
return request(app).get('/some/endpoint')
.expect(200)
.expect(res => {res.body.should.deep.equal(bodyValue)});
// How would I place code in here to check that MyMiddleware is called?
// ie. sinon.assert.calledOnce(MyMiddleware)
});
I have thought about using Sinon's spy, but I can't think of how to hook into the middleware... My attempt was this:
const mwSpy = sinon.spy(require('path to middleware file'));
sinon.assert(calledOnce(mwSpy));
The usual way of going about this is splitting this into two tests, an integration test and a unit test.
Will the middleware I specified in the router.get call end up being called when someone hits this endpoint?
Does my middleware do the right thing?
The first part is basically testing that the Express API is doing what the documentation says. That's not what unit tests are for (this was tagged unit-testing), but since you are already using HTTP requests to test the endpoint, I guess that's not what you are after anyway: you are basically creating verification tests for your system.
You could still test the Express routing without HTTP, though, as I detail in the answer to this question, concerning how to test the router programmatically (faster tests, no http), but less just stick to what you have.
So the basic question is: "My quest is to check that the middleware is called once from my unit test". You don't seem to concern yourself with whether the middleware is doing the right thing or not, just that it's called, which calls for the question on whether we should test the middleware or the layer using the middleware.
In both cases, you need to find a way of injecting a test spy. Either you write a small utility method that will inject that spy: function setMiddleware(module){ middleware = module; } or you use some tooling like proxyquire. See this tutorial on Sinon's homepage for background.
I would just do this (in the test code):
it('Should return whatever from GET call', () => {
var middlewareFake = sinon.fake();
// I am assuming it's the actual app object you are referencing below in the request(app) line
var app = proxyquire('../app/index.js', { './my-middleware': middlewareFake });
//
return request(app).get('/some/endpoint')
.expect(200)
.expect(res => {
res.body.should.deep.equal(bodyValue)
expect(middlewareFake).was.called;
});
});
I was wondering if there is some standard pattern to be able to use describe and it correctly. I am testing a node application so my tests are stored under a directory called tests in the root.
I was trying to understand how to use describe. My first thought is to use class names and method names as describe and then different test situations for the method using it. I suppose something like this.
describe ('Calculation Class')
describe ('getSquaredArea()')
it('should return correct value if passed a valid numeric')
/* one situation */
it('should return null when the value passed is not a numeric)
/* another situation /*
Is this recommended using the method name, understanding that in the calculation class will be a number of different methods?
I suppose my question refers to either mocha or jasmine or jest.
I was also thinking about testing the front end and I was thinking about using the same pattern above but removing the first describe as the tests will be stored with the file they are testing and not separately in the test root directory.
I am not sure about the second describe above, just playing the method name there.
Your mocha test should look like this.
var testObj;
describe ('#User', function () {
beforeEach(function () {
//init what the object contains
testObj = new DataStore(data, Container);
});
describe ('Admin', function () {
//other tests
});
it ('#Should return the name of the user', function () {
assert.equal(testObj.get('user'), dummyData.user);
});
it("should offer simple HTTP request capabilities", function () {
return chakram.get("http://httpbin.org/get");
});
});
I know, Browserify isn't really a DI framework, but is it possible to "inject", or somehow fake injecting, mock data into an application during unit testing?
For example, to test the function:
var MyModel = require('./models/My.js');
function doSomething() {
// do something with model.
}
with a mock My.js, like
describe('Do Something', function() {
beforeEach(function() {
// replace './models/My.js' with a Mock implementation.
});
it('with model', function() {
// ... test
});
})
what goes in the beforeEach function?
There are a few tools for mocking require calls in browserify.
https://github.com/thlorenz/proxyquireify
https://github.com/i-like-robots/rewireify
https://github.com/thlorenz/browserify-swap
https://github.com/Colingo/mock
https://github.com/mfncooper/mockery
I haven't personally used these. Also, mockery wasn't written with Browserify in mind so mockery might not even work. The others were written for Browserify though so they should work with little effort. :) Proxyquireify and Rewireify seem to be the only 2 active within the last year though.
I am completely new to D3JS and would like to understand the testing strategies for D3 JS.
To elaborate little more on question - consider I have a simple page that shows a line graph using a TSV file.
Java Script Code:
function LineManager() {}
function LineProperties() { // Line Properties }
LineManager.prototype.draw = function(properties) {
// D3 code to draw a line with the given properties.
}
I am not able to think of test cases to be considered for writing unit tests. Here is a sample test that I wrote ..
it("should throw an exception if line graph properties are not set.", function() {
expect(lineManager.draw.bind(lineManager)).toThrow("Line Graph properties not set");
});
it("It should have single line chart", function() {
lineManager.draw(properties);
expect(lineManager.countLines()).toEqual(1);
});
I have written unit tests to make sure the TSV file is getting generated correctly. But does it make sense to write a unit test to see if the data is getting rendered correctly? Isn't that more of a d3js unit test rather than unit test for my function?
So my question is - what tests should be considered for charts generated by d3js?
I think I got the answer to my own question. Will try to explain it here.
It is not possible to validate whether the graph is plotted correctly by JS function written using D3JS. For this we may have to use Phantom.js or similar framework as mentioned by Chrisopher. I was not worried about making sure D3JS is plotting graph correctly, as any ways it is D3JS functionality and my code can safely assume D3JS is doing its work.
My worry is more of whether the data passed to D3JS is correct and as per my requirement. It is very much possible to make sure the properties of the graph are set correctly by creating Spy objects. I am providing a sample unit test covering test cases for a JS code plotting a Circle using D3JS.
CircleManager.js
function CircleManager() {};
CircleManager.prototype.draw = function(radius) {
var svg = d3.select("body")
.append("svg");
svg.attr("width", 100)
.attr("height", 100);
var circle = svg.append("circle");
circle.style("stroke", "black")
.style("fill", "white")
.attr("r", radius)
.attr("cx", 50)
.attr("cy", 50);
};
CircleManagerSpec.js
describe("draw", function() {
it("Constructs an svg", function() {
var d3SpyObject = jasmine.createSpyObj(d3, ['append', 'attr']);
// Returns d3SpyObject when d3.select method is called
spyOn(d3, 'select').andReturn(d3SpyObject);
var svgSpyObject = jasmine.createSpyObj('svg', ['append', 'attr', 'style']);
// Returns svgSpyObject when d3.select.append is called.
d3SpyObject.append.andReturn(svgSpyObject);
d3SpyObject.attr.andCallFake(function(key, value) {
return this;
});
svgSpyObject.append.andReturn(svgSpyObject);
svgSpyObject.attr.andCallFake(function(key, value) {
return this;
});
svgSpyObject.style.andCallFake(function(key, value) {
return this;
});
var circleManager = new CircleManager();
circleManager.draw(50);
expect(d3.select).toHaveBeenCalledWith('body');
expect(d3SpyObject.append).toHaveBeenCalledWith('svg');
expect(svgSpyObject.attr).toHaveBeenCalledWith('r', 50);
expect(svgSpyObject.attr).toHaveBeenCalledWith('width', 100);
expect(svgSpyObject.attr).toHaveBeenCalledWith('height', 100);
expect(svgSpyObject.style).toHaveBeenCalledWith('stroke', 'black');
expect(svgSpyObject.style).toHaveBeenCalledWith('fill', 'white');
});
});
Hope this helps.
I think you should consider this: http://busypeoples.github.io/post/testing-d3-with-jasmine/
And it really seems to make sense. I have read the others' answers but I am little bit disagree with them. I think we not only check if right function is called or not but we can check much more than that. Checking only some function call are good at unit testing level but not enough. Such test cases written by developer will be based on developer's understanding like these functions are called or not. But whether these methods should be called or not, this thing can be only checked by going at another level because unlike other work, here are code is making something not returning something that can be just checked and make sure everything is correct.
We obviously don't need to check whether D3 is doing its work correctly or not. So we can use D3 inside our testing code. But D3 renders SVG and we can check things like if svg have elements where expected. Again it is not going to test whether SVG is showing and rendering properly or not. We are going to check if SVG have elements which are expected and they are set as expected.
For example:
If this is bar chart, we can check the number of bars. As in example in above link here it is check that.
// extend beforeEach to load the correct data...
beforeEach(function() {
var testData = [{ date: '2014-01', value: 100}, { date: '2014-02', value: 140}, {date: '2014-03', value: 215}];
c = barChart();
c.setData(testData);
c.render();
});
describe('create bars' ,function() {
it('should render the correct number of bars', function() {
expect(getBars().length).toBe(3);
});
it('should render the bars with correct height', function() {
expect(d3.select(getBars()[0]).attr('height')).toBeCloseTo(420);
});
it('should render the bars with correct x', function() {
expect(d3.select(getBars()[0]).attr('x')).toBeCloseTo(9);
});
it('should render the bars with correct y', function() {
expect(d3.select(getBars()[0]).attr('y')).toBeCloseTo(0);
});
});
// added a simple helper method for finding the bars..
function getBars() {
return d3.selectAll('rect.bar')[0];
}
Some people probably gonna say that we are going to use D3 inside testing code? Again we should remember that purpose of test writing here is not to test D3 but our logic and SVG code that is compiled in response to our code.
This is just a way and jasmine is something that is helping us in writing test, you can also go into more detail and in different scenarios. You can make domain and check datapoints width height to cross check if they result into data which were given to render.
I think I am clear if not then check this link : http://busypeoples.github.io/post/testing-d3-with-jasmine/
Here write of this article have explained things in detail with how you can use jasmine.
Also I think I am still gone into detail. If only unit testing is required at different js functions level then there are a lot more things which can be tested without going into elements detail.
Testing strategy
The strategy I end up using to test d3.js code is to create helper functions to manage my data and settings. I then unit test these functions. So for charts I would check every functionality dealing with data, every function to set width, legends etc...
Concerning drawing functions it can get trickier but with testing frameworks such as buster.js it can be quite easy to implement these too. A good way of testing a chart would be to count the number of bars/lines in the page, check that legends are printing etc.
I would not try to check that the chart is visually the same because visually checking that the end result is the same is easiest. However, when writing the drawing functions, one should be very attentive to what happens on updates (will changing the data draw twice as many lines? are selectors right? ...)
Javascript testing
A great book on javascript testing is: Test Driven Javascript Development. It provides lots of examples and strategies to test javascript code. Most of them can be directly applied to d3.js code.
Tools
I recently looked for solutions for unit testing d3.js code and I ended up using the following tools:
buster.js
Buster.js is a very complete framework for unit testing javascript code in multiple browsers.
phantom.js
Phantom.js is a headless WebKit scriptable with a JavaScript API.
This means that it makes it easy to run automated tests on javascript without needing to use browsers such as chrome, safari etc..
EDIT: I would now use jasmine for unit testing and selenium (through the Saucelabs service maybe) for end to end testing.
Probably worth mentioning Jest snapshot testing. Jest/snapshots are popular for React UI components, as they're also difficult to test. With D3 you could generate an SVG take a snapshot and verify as your codebase evolves that you continue to generate the same output.
function makeChart(id, dataset) {
const chart = d3.select(id)
.append("svg")
.selectAll("circle")
.data(dataset)
.enter().append("circle")
.style("stroke", "gray")
.style("fill", "black")
.attr("r", 40)
.attr("cx", 50)
.attr("cy", 20);
return chart;
}
it('renders correctly', () => {
const myChart = makeChart('#example', [1,2,3])
expect(myChart.node()).toMatchSnapshot();
});
This test is untested
A snapshot can be any output a string "Foo Bar" a JSON object {foo: "bar"} etc.
Basically you have to run a test once that contains .toMatchSnapshot. Jest will then manage the generation and store a copy that it'll compare in future tests.
The concept is similar to VCR in Ruby testing. Record and replay.
I'm using this library at the moment to try to get Handlebars working on the server side of my meteor app (https://github.com/EventedMind/iron-router#using-a-layout-with-yields).
I've gotten it to work but I now want to fix my unit test. I'm a bit of a beginner at Jasmine so hopefully this question isn't too stupid. Tell me if I'm completely on the wrong track.
At the moment I'm trying to mock this line in a jasmine unit test.
Handlebars.templates['ResponseToSubscribers']({dateSent: new Date()})
I know how to mock methods, but I'm not sure how to mock array values.
I've tried doing this.
spyOn(Handlebars, 'templates').andReturn({"ResponseToSubscribers": (obj) -> "html"})
but it's giving me this error.
templates() method does not exist
How can I mock [] and get it return something?
A small correction to the way of adding a spy will solve the problem. Spy registration has to be done to the object and function/value on that object. Modifying the registration to spyOn(Handlebars.templates, 'ResponseToSubscribers') will solve your problem.
Sample Code:
describe("Test Array", function() {
it("checks the actual value", function() {
var t1 = Handlebars.templates['ResponseToSubscribers']('dummy');
expect(t1).toEqual(1);
});
it("checks handle bar value", function() {
spyOn(Handlebars.templates, 'ResponseToSubscribers').and.returnValue(2);
var t = Handlebars.templates['ResponseToSubscribers']('dummy');
expect(t).toEqual(2);
});
});