When I first started building out my latest project, I went all-in on unit tests with heavy mocking. Every service, database call, and external API was stubbed out. My test suite ran in milliseconds, and seeing a wall of green checkmarks felt incredible. But then came the first deployment to staging—and almost everything broke. Mocked tests only verify your assumptions about how dependencies behave, not how they actually interact in the real world.
As I've been building in public, I've shifted my strategy toward lightweight integration tests using tools like Testcontainers. Instead of mocking the database, I spin up an ephemeral, real instance during the test run. It adds a few seconds to the CI pipeline, but catching schema mismatches, missing indexes, and SQL syntax errors before reaching production saves hours of debugging later.
How do you strike the balance between fast unit tests and reliable integration tests in your current workflow? Do you lean heavily on mocks for execution speed, or do you prioritize testing against real dependencies? Let me know your thoughts below!
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.