Welcome to the final part of this review of the Pluralsight course Node.js Testing Strategies by Rob Conery

Rob has been working in the technology field full time since 1998 as a DBA and then a web developer.

His original focus was the Microsoft ASP.NET stack, building tools like Subsonic and the first Micro-ORM: Massive. He co-founded the online training site Tekpub.com with James Avery and co-host This Developer’s Life with Scott Hanselman.

Tekpub was bought out by Pluralsight and he worked there for two years. He is currently working on a new book called The Imposters Handbook.

Also in this series:

Part 1 – Introduction
Part 2 – Simple Tests with Node.js and Mocha
Part 3 – Data Access Considerations
Part 4 – External APIs

External APIs

A Look at Stripe

Rob loves Stripe.com and highly recommends it. The documentation is exceptionally good and it is all very nicely designed.

The only caution that I would give is to be careful when typing in the URL – I missed off one letter and ended up on a XXX site :-S

In this lesson Rob runs through the subscriptions part of the API docs.

Making a Test Call

We see how to call stripe.customers.create.

To install stripe:

npm install stripe –save

This also pulls in:

TJ Holowaychuk and Jordan Harbans’s qs querystring parser

Petka Antonov’s bluebird promise library

John-David Dalton’s Lodash utility library

Stripe sends us back a large piece of JSON with the details we are after.

We can use the stripe test dashboard to check that everything is correct.

And we can use the response message as a helper method.

The Billing Process

Rob creates skeleton methods for Billing functions: creating, cancelling and changing a subscription.

We see that we can use the NodeJS assert in our production code: instead of doing if not null, or if truthy checks we can assert truthy and the objects will throw an exception if they are falsy.

Rob shows us how to write an integration test for createSubscription, and it passes.

Stubbing Stripe

We write out startSubscription function and we need billing information sent into it.

In our test we send in the card as 1 (not an object as we would for the live system)

We see how to use Sinon to stub createSubscription to return “XYZ” as our id.

By the end of this lesson we have the happy path working well.

Handling Stripe Failure

How to test the sad path.

We create objects for goodStripeArgs and badStripeArgs and then chains Sinon’s withArgs method with the yields to return the good stripe response for the good stripe arguments, and returns the bad stripe response for the bad stripe arguments.

However Rob warns to tread lightly! We later refactor to use a billingStub object instead of trying to restub.

The idea behind making all of these mistakes is to show an organic development process.

We see further testing problems as we progress through this lesson, and how to overcome them.

Rob concludes by saying Singletons and caching in Node == PAIN.

Mocks with SinonJS

Mocks are like spies but they also have pre-programmed expectations.

Rob rarely uses them, and I agree with him, but that is really just a stylistic preference.

Rob shows us an example of using a sinon mock. It can reduce the amount of code that we need to write, but see my article easier to read, harder to misread to understand my viewpoint better.

Simplifying Things with Nock

Rob warns that mocking can make you want to smash your head against the wall!

Pedro Teixeira began the Nock project and over a hundred others have helped him to make it what it is today.

It is a HTTP mocking library which mocking the HTTP calls from our code to an external API.

npm install nock –save-dev

Nock uses the following dependencies:

• propagate (also by Pedro)
• lodash utility library
• Nathan Rajlich’s and TJ Holowaychuk’s debug utility
• James Halliday’s mkdirp
• Keith Cirkel’s chai assertion library

We require nock into our review_spec.js.

Then we can remove a dozen lines of sinon mocking code and replace it with just 3 simple lines of nock code for the happy path.

Testing the sad path is a more tricky, and something that forced Rob into significant research in order to present the lessons here.

A good mantra is:

Don’t mock something you don’t own.

You might also want to check out supertest. For more info on that see RESTful Web Services: Testing.

Involving the Database

Rob says many Ruby, Node and Python developers prefer to test the database rather than mocking it.

For this approach Rob recommends Louis Chatriot’s nedb database. It stands for Node embedded database and you can think of it as SQLite for Node.js.

In this lesson we see how to use it to write our tests, and they run a lot faster than you might think: 27 passing tests in 61 milliseconds.

The performance argument for mocking isn’t as strong as it used to be.

Rob also talks about his Massive JS project. We see 133 passing tests in 2 seconds.

I think this is a very good testing per second ratio and that it shows that the “test as little as possible” argument is a long way from the whole story.

Summary and Parting Thoughts

The main point of this course has been to demonstrate that testing is a recursive process and that we need to listen to what our tools are telling us.

This review is of course intended to complement, not replace this course. I hope that you enjoy watching as much as I did.