Parallel Continuous Integration: Blazing End-to-End Testing

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.

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.

Wrapping Up/Resources

End-to-end testing can be fast and can give you feedback while developing, and don’t just have to be a safety net that you run once a day.

• Velocity: Meteor testing framework

Looking for something else? Check out our full library of PubNub talks here.