open sky
Hey everyone, I have a question regarding testing in Backstage.
Our repository standard requires a test folder that includes three types of tests:
1. Unit tests – to verify logic and behavior within a component.
2. Integration tests – to test interactions between two or more components with virtualized dependencies.
3. Intervention tests – to test the entire system at the plugin level.
Plugin A
|— src
|— test
|— unit
|— integration
|— intervention
I assume we’d follow a similar approach for the Backstage UI, especially to verify whether plugins are visible and working as expected.
The main concern we’re facing is related to build performance. As more plugins are added, the test suite will grow significantly, and we want to avoid slow build times. Since we’re working in a monorepo, we’re exploring strategies to manage this effectively.
We’ve come across the idea of selective testing, where only tests in plugin folders that have changed are executed. Is this something Spotify is using internally, or do you have other recommendations on how to handle test scaling in a monorepo?
Also, we’d love to hear if there’s a way to customize the plugin scaffolding structure when onboarding new ideas into Backstage, particularly to ensure test structure consistency.
fiery helm
candid wagon