Hey folks, I've been experimenting with speeding up our test suite execution in CircleCI. Our monorepo's integration tests were becoming a real bottleneck, taking over 25 minutes to run sequentially. I knew parallelization was the answer, but I wanted to avoid overly complex or expensive solutions.
After some tinkering, I landed on a method using CircleCI's built-in parallelism and dynamic splitting. The key was using the `circleci tests split` command with the `--split-by` flag. Instead of relying on timing data (which can be flaky), I split by the actual test file names. Here's the core of the `config.yml` for the test job:
```yaml
jobs:
run_integration_tests:
parallelism: 4
docker:
- image: cimg/node:18.17
steps:
- checkout
- run:
name: Split test files and run
command: |
# Find all test files and split them across parallel containers
TESTFILES=$(find ./integration -name "*.test.js" | circleci tests split --split-by=filenames)
echo "Running tests: $TESTFILES"
npm run test:integration -- $TESTFILES
```
This approach required minimal config changes. The `parallelism: 4` spins up four identical containers. Each container gets a unique subset of the test files, and the `npm run` command executes only that subset. The total runtime dropped from 25+ minutes to just under 7 minutes, which is basically the runtime of the slowest single container's batch.
I'm curious if others have tried similar strategies. Have you found splitting by filenames to be reliable, or do you prefer another method like splitting by timing data? Also, how do you handle the test results aggregation? I'm currently using a JUnit formatter and the `store_test_results` step, which works okay, but I wonder if there's a more elegant way to visualize the combined output across all parallel runs.