Loading...
Loading...
Browse 5 real-world technical and behavioral interview questions about Contract testing. Review scenarios, edge cases, and architectural best practices.
The contract captured the shape the consumer sends, not the rules the provider enforces. Optionality lived in the schema while the real requirement lived in provider validation, and no recorded example ever omitted the field. Contract tests only verify interactions they contain, so add the negative example and verify against real code.
Contract testing has each side verify itself against a shared description of the interaction, so consumer expectations are checked against the provider's real behaviour without the two ever running together. Mismatches surface in each team's own pipeline, not in a shared environment days later. It also connects api testing to the point an interviewer is testing.
Separate contract tests, which check shape and backwards compatibility cheaply, from integration tests that exercise real behaviour across real dependencies. Make every test create and own its data so the suite is re-runnable, spend most of your negative cases on authorisation and malformed input.
Additive changes with defaults are safe, removals are not, so split every removal into deprecate-then-delete with evidence that nobody reads the field. Register the schema, pick a compatibility mode deliberately, and note that backward compatibility requires consumers to deploy first.
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.