Loading...
Loading...
Browse 6 real-world technical and behavioral interview questions about Testing. Review scenarios, edge cases, and architectural best practices.
Substitute at the network layer or behind your own client interface, not at the HTTP library's function. Stubbing the library couples the test to how you make the call rather than to what you send, so the test keeps passing through refactors that change the request and breaks on refactors that change nothing.
Drive business logic through injected dependencies rather than module mocks, intercept at the process boundary for outbound HTTP and time, and use a real database in a container for anything where the database is the logic — SQL, constraints, transactions and migrations.
The failing test is a victim, not the cause: something earlier mutated state it shares, usually a module evaluated once, a global that was patched and not restored, or rows left in a database. Bisect the ordering to find the pair, then remove the sharing.
Pull a bounded, representative extract into an environment you control and develop against that, keeping production for read-only verification under agreed limits, and treat every write path as something proven against a restored copy before it runs anywhere near live.
Wire dependencies explicitly through constructors from one place in main, define narrow interfaces where they are consumed rather than implemented, and keep handlers thin enough that the logic beneath is testable without a server. With no framework, these are decisions rather than defaults.
Make time and scheduling injectable. Take a java.time.Clock as a dependency so a test can fix it, and replace a fixed sleep with a bounded poll on the observable outcome, so a fast machine does not wait and a slow one does not fail.