As your product grows the number of tests will grow. At one point, the number of tests overwhelm the number of servers to run those tests, developer feedback becomes slower and bugs can sneak in. To solve this problem, we built parallelization into our Jenkins build pipeline, so we only need to add servers to keep overall test time down. In this talk, I'll cover how we did it and what came out of it in terms of pros and cons.
As your product grows the number of test grows. At Tradeshift, we develop code in a test-driven manner, so every change, be it a new feature or a bug fix, includes a set of functional tests driven by Selenium.
At one point, it started taking too long to run all of our tests in sequence, even when we scaled capacity of test-servers to make the individual tests run faster. When tests are slow developers don’t get immediate feedback when they commit a change and more time is wasted switching between tasks and different parts of the code. To solve this problem, we built parallelization into our Jenkins build pipeline, so we only need to add servers to make our test suites run faster and keep overall test time down. In this talk, I'll cover how we did it and what came out of it in terms of pros and cons.
