The Test SDK: The SDET's Best Friend In Monolith-To-Microservices Migrations
summary
uShip builds an internal Test SDK (published to an internal npm registry) to centralize test data creation and core helpers so one API change no longer forces 20 PRs across repos. Version 1 takes ~3–6 months to reach usable state, it bundles Playwright and Allure integrations, runs on Node (now v20), and uses semantic release for nonbreaking updates. It reduces duplicated helpers, speeds test setup, but requires ongoing maintenance, ownership and data cleanup.
AI-written summary · about
chapters (16)
- 0:00Test SDK concept
- 2:29Why uShip built Test SDK
- 6:41Microservice testing problems
- 10:53What is Test SDK
- 11:58Centralized test data
- 15:09Manual QA use cases
- 16:55Standardizing test architecture
- 22:07Easy maintenance updates
- 24:33Tips for building Test SDK
- 33:21Test SDK challenges
- 37:10When not to use Test SDK
- 38:43Q&A: Off-the-shelf vs custom
- 41:43Q&A: Framework integration
- 46:01Q&A: Maintenance vs delivery
- 47:46Q&A: Developer adoption roles
- 50:12Q&A: Regression smoke testing
related talks
27mFullstack testing
18mAt the top of the pyramid: Playwright testing at scale
12mPlay It Right With Playwright
23mAdaptive Testing
37mFrom Rigidity to Resiliency: An Evolutionary Tale of Selenium-Based Frameworks
54mTesting for products with a microservice architecture
51mAdvanced Playwright Techniques for Flawless Testing
40mStrategic Business Functionality Testing: Accelerating Development Through Mocking