Just like peanut butter plus jelly is a satisfying and delicious combination of two otherwise individual ingredients, CasperJS plus data-mocking is a powerful and effective pairing of two otherwise individual tools. However, whereas bringing peanut butter and jelly together in a sandwich is pretty straight-forward and requires a bare minimum of instructions, getting CasperJS and data-mocking libraries like Sinon.JS and Mockjax to play well together takes some effort. However, the awesomeness that you get when putting CasperJS and these data-mocking libraries together dwarfs the amount of information available explaining exactly how to do that. I'm going to take a stab at fixing that.
Before we get into it, let's make sure we're on the same page - especially with regard to when and why you'd want to go the CasperJS plus data-mocking route.
CasperJS, Sinon.JS, and Mockjax
Mockjax is a library that provides the ability to mock or simulate Ajax requests and responses, making a server unnecessary (when testing).
In unit-testing land, mocking-out your datasources or data-access components to create truly data-independent tests is a common practice. But, this is a common developer practice. Data-mocking is not something that I see many test engineers practice or pursue.
And so, for a long time, we've seen the evolution of a divided highway. On one side, developers build and tend to their low-level, data-independent unit tests. On the other, testers build and tend to their high-level, browser-based, data-dependent automation tests.
The Power of CasperJS
Anyway, cut to the chase - we can. What you want to do is toss Sinon.JS and/or Mockjax in there to mock all of your data requests.
For Ajax-Driven Sites
Just like a well-constructed and well-tended suite of unit tests breeds confidence among developers when it comes time to refactor or modify user-invisible components, a similarly-loved suite of functional tests does the same with respect to those components with which your users are intimately familiar. That's why you want this ability.
But, front-end unit testing can only take you so far. A significant portion (the majority, I'd say) of that front-end code is impacted by and/or dependent on complicating factors such as the browser runtime, timing issues, the prior sequence of actions taken by the user, rendering of the markup, etc. Being able to account for all of that, in a controlled manner, brings your focus in much closer alignment with that of your users.
Capybara also has a Ruby on Rails bias, which imparts on it a bias toward full-stack, database-dependent tests. If your site is backed by a clean, unified, rational database, you should be good to go with Capybara. Stand-up and tear-down your test database to your heart's content. But, for sites backed by a convoluted mess of multiple legacy datasources, the stand-up/tear-down thing just isn't feasible. If you're in this boat, the CasperJS plus data-mocking route is probably the route best taken.
If you've got a site where most/all of the data is being delivered straight to the browser via Ajax-delivered payloads, you're going to want to start functionally-testing it using a combination of CasperJS and data-mocking. Because having the same level of confidence in- and focus on- the high-level interactivity of your GUI that you have always had in/on the lower-level logic of your user-invisible components is just plain powerful - in a way that most benefits your users.
That's it for the "when" and "why". Hopefully, you have a site that can benefit from being tested with CasperJS plus data-mocking - and I've convinced you that doing so is very much worth your while. In my next article, I'll set about explaining the "how".
Read the follow-up to this article - How To Use CasperJS with Mocked Data to Test Your Site’s UI
Many thanks to Jonathan Julian for reviewing a draft of this article.