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: 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.
- Explain: 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.
- Explain: 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.
- test where two individually correct components still disagree
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 ViewTests the boundary Integration tests exercise the interface where two components meet, not the inside of either one.
- Catches disagreementTwo parts that each pass their unit tests can still encode a shared contract differently; the boundary is where that shows.
- Observe the far sideThe evidence is what the connected consumer, store, or device actually received, not just what the producer sent.
- Beginner ExamplesRead 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.
- 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.
Major section
Practitioner: Contracts, Order, and the Unhappy Paths (continued)
The decoded value and status the firmware actually uses.
- 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.
- The value the service stores or returns to the device.
- Interrupted write, missing key, or a schema change.
Major section
Practitioner: Contracts, Order, and the Unhappy Paths (continued)
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.
- 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.
- The state the gateway or app shows after the event.
- 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.
Major section
Under the Hood: Contract Drift, Stub Divergence, and Shared State
Shared State and Timing Make Tests FlakyIntegration 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 RealityIntegration 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 PitfallsReview 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
Integration testing checks whether connected parts of an IoT system agree at their boundaries; it sits between isolated unit checks and full system validation.
- 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.
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 ViewTests 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 can this happen?
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.
Q2What should the review require for the changed device status value?
Show answer
Answer: C 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?
Show answer
Answer: B 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.
- C · 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.
- B · Independently green suites can both be stale; making the shared contract the thing under test catches a one-sided change immediately.