One of the most impactful core features of Nx is the affected graph. The affected graph helps us to skip unnecessary work and focus only on the things that have been changed significantly speeding our CI and helping us ship features and hotfixes faster.
However, long-running test tasks, especially End-to-End (E2E) tests, can become a significant bottleneck and prevent getting the code changes out faster. This is particularly true for monolithic projects, but also cases when there is a single large E2E project that covers the entire scope of the application. In this case the full benefits of an affected graph cannot be realized.
In this guide, we'll explore three techniques to speed up your CI by splitting these lengthy test tasks.
Built-in Test Sharding
One of the simplest ways to split long-running tests is by using built-in test sharding features available in popular testing frameworks like Jest and Playwright. These tools allow you to divide your test suite into multiple shards that can be executed in parallel, significantly reducing the percieved test execution time.
In Jest we can utilize the new --shard option to split your test suite. The example below shows splitting into 4 shards.
❯
nx affected -t test -- --shard=1/4
❯
nx affected -t test -- --shard=2/4
❯
nx affected -t test -- --shard=3/4
❯
nx affected -t test -- --shard=4/4
Playwright also supports --shard option:
❯
nx affected -t e2e -- --shard=1/4
❯
nx affected -t e2e -- --shard=2/4
❯
nx affected -t e2e -- --shard=3/4
❯
nx affected -t e2e -- --shard=4/4
Now that we have our tests sharded, we can distribute the test load, and achieve faster feedback.
But what about the test runners that don't support sharding?
Nx Atomizer
For more granular control over test distribution, Nx offers the Atomizer. This feature allows you to split tasks per file. Splitting then further allows us to distribute long running tasks across larger number of agents, providing detailed insights into flaky tests and enabling automatic re-runs. If one of the flaky tests fails, we will still cache the results of all the other task slices and can even have a successful run if the flaky test re-run succeeded.
With Atomizer, you can achieve a higher level of parallelism and ensure that only the necessary tests are executed, further optimizing your CI pipeline.
To enable atomizer, we need to use supported inferred plugins or create our own.
1{
2 // ...
3 "plugins": {
4 {
5 "plugin": "@nx/cypress/plugin",
6 "options": {
7 "targetName": "e2e",
8 "ciTargetName": "e2e-ci",
9 }
10 },
11 {
12 "plugin": "@nx/playwright/plugin",
13 "options": {
14 "targetName": "e2e",
15 "ciTargetName": "e2e-ci"
16 }
17 },
18 {
19 "plugin": "@nx/jest/plugin",
20 "options": {
21 "targetName": "test",
22 "ciTargetName": "test-ci",
23 }
24 },
25 {
26 "plugin": "@nx/gradle",
27 "options": {
28 "classesTargetName": "classes",
29 "buildTargetName": "build",
30 "testTargetName": "test",
31 "ciTargetName": "test-ci"
32 }
33 }
34 }
35}
36The test-ci and e2e-ci targets will automatically be split into following format:
e2e-ci--path/to/your/test/filetest-ci--path/to/your/test/file
You can find more information on how to configure the atomizer on the respective Jest, Cypress, Playwright, Gradle or follow this recipe to create your own inferred plugin.
Manual E2E Project Splitting
In addition to automated splitting like sharding or atomizer, manually splitting E2E projects into scopes can provide significant performance benefits.
Let's look at the simplified graph below: 
Our E2E project contains tests for each of the apllication features - products, orders and checkout. Any change made in the graph will cause all our E2E tests to be re-run. Even if we only modified products, we will still re-run the tests for orders and checkout. Although atomizer will help us split that work per file and distribute it, we will still end up running unnecessary work.
By defining scopes that implicitly depend on feature libraries rather than the entire application, you can ensure that only relevant tests are run when changes are made.
- Scope Definition: Break down your E2E tests into smaller, focused scopes.
- Dependency Management: Ensure that scopes depend on specific feature libraries, reducing unnecessary test execution.
This approach, offers both speed of distribution and caching efficiency. Every time the application is affected, we will only run the small subset of sanity smoke tests to ensure the application still runs, but specific features will only be tested if relevant feature library has been modified or affected and skipped otherwise.
The tricky part comes from the fact that our split E2E applications still depend on the full application being served. But using the combination of implicitDependencies and dependsOn we can ensure that the application is running for our E2E tests without explicitly depending on it.
1{
2 ...
3 "implicitDependencies": ["checkout"],
4 "targets": {
5 "e2e": {
6 "dependsOn": ["^build", { "target": "build", "projects": "app" }]
7 }
8 }
9}
10When we look at the graph, we will only see an edge from checkout-e2e to checkout, but having an explicit dependsOn app:build ensures that the build of the application was successful and the distributed agent running our E2E task has app's build cache replayed.
Conclusion
By implementing these techniques — the built-in test sharding, Nx Atomizer, and manual E2E project splitting — you can significantly reduce the time spent on CI. Sharding requires the liest amount of work to be enabled but also brings the liest amount of benefits. Respectively, manual splitting requires most work as it's not an automated process, but the final results will be most optimal ones.
Which ever path you take, when combined with Nx Cloud's distributed task execution, these strategies not only bring stability and improved performance but also offer better developer ergonomics and a comprehensive overview of your testing processes. This powerful combination allows your team to ship features faster and with greater confidence, ensuring a more efficient and streamlined development workflow. If you're not already using Nx Cloud, consider trying it out to further elevate your CI capabilities.
