Integration testing with Bazel
summary
Dropbox migrates integration tests into Bazel by building a declarative services framework that encodes service binaries, a service daemon rule with HTTP health checks, and a dependency graph so Bazel starts services before tests run. A service controller (aka service cuddle) and svc_lib let tests create, stop and restart services dynamically; itest opens a debug shell. The system runs up to 107 services with a 58s critical startup, works but inflates CI memory and encourages excessive end-to-end tests, so unit-test incentives follow.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:07Dropbox dev infra
- 2:34Integration testing challenges
- 5:01Services framework for Bazel
- 7:26Basic integration test
- 8:51Tests with service dependencies
- 9:58Service dependencies in Bazel
- 10:43One-shot services setup
- 11:25Dynamic service control
- 12:49Service controller daemon
- 13:32Declarative service config benefits
- 14:37Standardizing dev workflows
- 15:21No to non-hermetic tests
- 16:26Interactive development
- 19:00Services framework limits
- 21:53Did integration testing get too easy?
- 22:57Performance costs of service trees
- 25:10Learning from testing literature
- 25:52Unit testing over integration
related talks
19mAutomatic Testing for Services at Scale
08mWhy We Should Care About Test Execution Output in Safety-Critical Industries
11mLightning Talk – Testing Bazel’s Remote Execution API
45mSelective Testing + Q&A
33mFewer, Smarter, Faster: Scaling Testing @Spotify
25mCost-effective and easy to maintain GraphQL integration tests (zio-test and Caliban)
28mContinuous Integration Testing: Fully Test your Microservices Application, Early and Often
40mScala, Docker and Testing oh my!