Testing & Validation · Study deck
Integration Testing for IoT Systems
A temperature driver can pass its unit tests, and a cloud uploader can pass its unit tests, while the product still fails because one side sends tenths of a degree and the other reads whole degrees.
Test Tessa is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Two failure patterns dominate: a test that leaves state behind so the next test sees a dirty environment, and a test that asserts before an asynchronous result has arrived, passing or failing by luck of timing.
- Explain: Contract tests formalize this by checking the producer and the consumer independently against the same agreement, so a drift on either side fails fast instead of surfacing only when the whole system is assembled.
- Explain: It sits in the middle of the testing pyramid — fewer, slower tests than unit, but far more targeted than a full end-to-end run.
Major section
Overview: Where Two Correct Parts Still Disagree
A unit test proves that a parser, driver, or state machine works on its own.
- It sits in the middle of the testing pyramid — fewer, slower tests than unit, but far more targeted than a full end-to-end run.
- Each crew measures carefully and builds a flawless half.
Major section
Overview: Where Two Correct Parts Still Disagree (continued)
Each side is "correct" against its own idea of the contract, and only a test at the boundary reveals that the two ideas differ.
- If you only need the intuition, this layer is enough: integration tests exercise the boundary between connected parts and check that they agree on the contract.
- Unit tests prove each part alone; integration tests prove the parts actually fit together, which is where many IoT defects hide.
- If they used different reference points, both halves can be individually perfect and still fail to meet in the middle.
Major section
Overview: Where Two Correct Parts Still Disagree (continued)
Unit tests inspect each half; the integration test is standing where the spans are supposed to join.
- The first step reuses unit-level evidence without assuming compatibility; the contract states the common expectation; and the observation proves what actually crossed the boundary.
- The boundary decision, evidence record, and retest trigger then make the result durable.
- This path connects two locally correct parts to the explicit agreement an integrated system needs.
Major section
Overview: Where Two Correct Parts Still Disagree (continued)
The One-Minute View Tests the boundary Integration tests exercise the interface where two components meet, not the inside of either one.
- Catches disagreement Two parts that each pass their unit tests can still encode a shared contract differently; the boundary is where that shows.
- Observe the far side The evidence is what the connected consumer, store, or device actually received, not just what the producer sent.
- Beginner Examples Read these examples as a progression from the simplest observation to the boundary that still needs evidence.
- If you can explain why two correct parts can still disagree, you have the core idea.
Major section
Practitioner: Contracts, Order, and the Unhappy Paths
The unit of integration testing is the contract — the agreement between two parties about what crosses their boundary.
- Contract tests formalize this by checking the producer and the consumer independently against the same agreement, so a drift on either side fails fast instead of surfacing only when the whole system is assembled.
Major section
Practitioner: Contracts, Order, and the Unhappy Paths (continued)
The decoded value and status the firmware actually uses.
- Incremental order needs test doubles to stand in for the parts not yet wired up, which is the same discipline used in unit testing, applied one layer out.
- At each step, retain the stimulus and far-side observation; that sequence connects a failing exchange to one diagnosable contract.
- The value the service stores or returns to the device.
Major section
Practitioner: Contracts, Order, and the Unhappy Paths (continued)
Scope identifies the components and versions; the contract states the expected exchange; the stimulus crosses that boundary; and the far-side observation proves what actually arrived.
- This order makes incremental integration diagnostically useful: when a new step fails, the evidence points to the newly connected contract instead of an undifferentiated whole system.
- Interrupted write, missing key, or a schema change.
- The state the gateway or app shows after the event.
Major section
Practitioner: Contracts, Order, and the Unhappy Paths (continued)
A common IoT trap is testing only on a perfect bench network; loss, latency, and disconnection are part of the contract and belong in integration tests with the network impairment simulated.
- For each, the record should name the contract, the stimulus that reaches the changed behavior, the observation on the far side, the decision, and the retest trigger.
- A pass that never observed the consumer, the store, or the device after the event is not yet boundary evidence.
- If you can name the contract, pick an integration order, and drive the unhappy paths, you can stop here.
Major section
Under the Hood: Contract Drift, Stub Divergence, and Shared State
Shared State and Timing Make Tests Flaky Integration tests touch databases, brokers, queues, and networks — stateful, asynchronous, and often shared.
- Both sides are green, yet the live boundary is broken.
- The stub is only as trustworthy as its fidelity to the real interface.
- Any change to a field, unit, or status code.
Major section
Under the Hood: Contract Drift, Stub Divergence, and Shared State (continued)
As with any layer, an intermittent integration failure is a defect to diagnose, not a job to rerun until green.
- Three mechanisms cause most of the quiet failures: a contract that drifts on one side, a service stub that diverges from the real thing, and shared state or timing that makes tests lie intermittently.
- Consumer tests run against a frozen fixture, not live output.
- An assertion runs before the result arrives.
Major section
Under the Hood: Contract Drift, Stub Divergence, and Shared State (continued)
Finish with Observing the sender, not the receiver.: Integration evidence is what the far side received, not what the near side sent.
- The Stub That Drifts From Reality Integration tests frequently replace a slow or remote dependency — a cloud endpoint, a third-party service — with a stub.
- The stub still accepts what the real service now rejects.
- Loss and errors are never driven across the boundary.
Major section
Under the Hood: Contract Drift, Stub Divergence, and Shared State (continued)
If the real service starts returning a new error shape, paginating a response, or rejecting a payload the stub still accepts, the suite stays green while production fails.
- Two failure patterns dominate: a test that leaves state behind so the next test sees a dirty environment, and a test that asserts before an asynchronous result has arrived, passing or failing by luck of timing.
- Common Pitfalls Review these failure modes in the order they can weaken or invalidate the result.
- This sequence connects each warning to the evidence a reviewer should demand before accepting the claim.
Major section
Summary
Many IoT defects live between components, not inside them: two parts can each pass their own unit tests yet disagree on encoding, units, status codes, or timing.
- The unit of integration testing is the contract; contract tests check producer and consumer against one shared agreement so a one-sided change fails fast.
- Integration order matters: big-bang integration makes faults hard to localize, while incremental integration adds one boundary at a time and points at the boundary just connected.
- The most valuable integration tests drive the unhappy paths — malformed input, missing or late responses, link loss and reconnect, partial state — with network impairment simulated, and observe the far side.
Deck summary
Key takeaways
A unit test proves that a parser, driver, or state machine works on its own.
- Each side is "correct" against its own idea of the contract, and only a test at the boundary reveals that the two ideas differ.
- Unit tests inspect each half; the integration test is standing where the spans are supposed to join.
- The One-Minute View Tests the boundary Integration tests exercise the interface where two components meet, not the inside of either one.
- The unit of integration testing is the contract — the agreement between two parties about what crosses their boundary.
Retrieval practice
Recall check 1 of 3
Test Tessa says: answer from memory, then check your reasoning.
Q1Two IoT components each pass all of their own unit tests, yet the feature is broken when they run together. How does this happen, and which test level is designed to catch it?
Show answer
Answer: A Unit tests prove each part in isolation; the defect lives between them, which is exactly the boundary integration testing exists to check.
Retrieval practice
Recall check 2 of 3
Test Tessa says: answer from memory, then check your reasoning.
Q2A candidate changes the status value a device sends when it rejects a sensor reading. The parser's unit tests pass, but the integration record does not show what the consuming service received. What is the strongest review decision?
Show answer
Answer: A The changed behavior is a consumer-facing contract; integration evidence has to come from the far side of that boundary, not from isolated parser tests.
Retrieval practice
Recall check 3 of 3
Test Tessa says: answer from memory, then check your reasoning.
Q3A device team renames a field in the telemetry message. The device's unit tests and the cloud service's unit tests both still pass, but production telemetry breaks. The service's tests run against a captured fixture from before the rename. What happened, and what prevents it?
Show answer
Answer: A Independently green suites can both be stale; making the shared contract the thing under test catches a one-sided change immediately.
Print reference
Answers
Answer key.
- A · Unit tests prove each part in isolation; the defect lives between them, which is exactly the boundary integration testing exists to check.
- A · The changed behavior is a consumer-facing contract; integration evidence has to come from the far side of that boundary, not from isolated parser tests.
- A · Independently green suites can both be stale; making the shared contract the thing under test catches a one-sided change immediately.