Make TDD your front-end new year’s resolution with Cypress
In November 2015 I saw Brian Mann give a presentation on Cypress.io. It immediately felt like the future.
At the time I had challenged myself and my coworkers to improve our testing. I was working on code coverage for MarionetteJs, and I took what I had learned there to the day job. Unit testing in Mocha was fine, and it worked great for Marionette, but it hardly covered the app we were developing. We had Selenium tests, but those were frequently flaky and done as an additional step after development. Attempts to integrate Selenium testing with our developer workflow failed. There was too much friction and everything felt kind of hacky.
“The last tool that changed my workflow this dramatically for the better was git.”
By May I had early access to the beta for Cypress and wrote my first test. It was clear that I did not know what I was doing. Cypress felt very familiar and it used Mocha and Chai for test writing, but knowing where to start for my mature application was daunting. My first error was to treat Cypress as a replacement for Selenium. While it can replace Selenium, I would highly recommend setting aside end-to-end tests for now and begin stubbing for integration tests.
After we began stubbing our server API we immediately saw workflow improvements. We weren’t even writing tests yet, but we were able to easily stub complicated data scenarios. We didn’t need to touch a database or setup a server. With some simple javascript we could setup every scenario we needed to cover to develop a new feature and then through cypress, interact with it, in our app, with excellent visibility into what was actually happening in the browser. Soon I stopped opening chrome to test my work and was exclusively using Cypress for development. The last tool that changed my workflow this dramatically for the better was git.
Let’s take a look at what this looks like in practice.
describe('User List', function() {describe('when there are users in selected group', function() {beforeEach(function() {cy.server().route('/api/users?group_id=*', 'fixture:users').visit('/users');});
**it**('should load the list page', function() {});
});
describe('when there are no users in group', function() {beforeEach(function() {cy.server().route('/api/users?group_id=*', []).visit('/users');});
**it**('should load the empty page', function() {});
});});
In this Cypress example, we have setup two data scenarios for different API results. In practice we might add describe.only to one of the scenarios so that we can develop in that environment. After running the “test” Cypress is a fully interactive Chrome instance complete with console.
The code example in Cypress. The left side is the interactive test results.
While this doesn’t scratch the surface of the promise and potential of Cypress, if this was all it did, it would be enough. In the first week of January I’m pleased to say we’re launching our first major feature that includes Cypress testing for every aspect. Additionally I am working with the Marionette team on possibly testing Marionette with Cypress, and while it was not designed specifically to test a library, everything is looking very promising. I hope to share more about what I’ve learned along the way soon.
Cypress should be public in the near future and I believe we’ll soon be questioning how we functioned without it. Get in on it now, and make Cypress and TDD your new year’s resolution. Cypress has an active and growing community, and while you don’t need access to run cypress headlessly, access to the GUI is currently by invitation during the beta. However getting access is easy; just ask in their gitter room.
Relevant Links: