Parallel Continuous Integration: Blazing End-to-End Testing

Subscribe to Our Newsletter

Stay updated with the latest on web, mobile, and IoT, delivered weekly.

Thanks for subscribing!

Get ready for some great content.

Traditional continuous integration (CI) has become a bottleneck in the development process. Why? Build pipelines are typically run sequentially. The release workflow starts on a developer machine, transitions to a build server, then gets deployed to QA. CI server causes significant delay, and valuable time is wasted due to feedback not being fresh enough.

In the talk below from the SF JavaScript Meetup, Sam Hatoum and Mike Risse discuss the idea of running an end-to-end build in < 10 seconds (including UI tests).

With Meteor 1.0 + Velocity, no matter the size of the application, bringing this closer to the developer workflow decreases feedback time and allows problems to be fixed much quicker.

The presentation also includes a live demonstration of parallel CI testing and Velocity, a Meteor testing framework, significantly reducing test time.

Parallel CI: Making End-to-End Tests Fast Enough to Run Every Time You Save from PubNub on Vimeo.

What is End-to-End Testing?

If you’re writing a web application, and end-to-end test is a test that runs against the UI. If you’re writing a service, then the test runs against the API. An end-to-end test accesses your system at the end that a user would access it, and runs the test end-to-end through your entire system. And end-to-end test looks at your system as if it is a black box.

However, end-to-end tests take a long time.

The Testing Triangle

The Testing Triangle says that you should write more unit tests than end-to-end tests simply because end-to-end tests take such a long time to run. With thousands of tests and high execution times, it’s going to take forever for your build to run. And that’s why the Testing Triangle tells you to push as much as you can down to the unit level.