beyond the UI

_posts/2025-09-26-beyond-the-UI.markdown

@@ -0,0 +1,78 @@
+---
+title: beyond the UI
+date: 2025-09-25T00:00:00Z
+categories:
+- Testing
+tags:
+- SoftwareEngineering
+- BackendTesting
+- QualityAssurance
+summary: This blog explores how mocking APIs can help teams test systems early, even when key parts aren’t ready. By simulating external services using tools like WireMock, developers can check data flows, handle errors, and improve quality without waiting for real APIs. Mocking supports faster development, better teamwork, and early bug detection. While it has limits—like needing updates when real APIs change—it’s a powerful way to build confidently. The experience shows that mocking isn’t just a shortcut; it’s a smart strategy for reliable software delivery.
+author: asaha
+---
+
+## Beyond the UI: A Story of Smart Mocking with WireMock
+
+## 1. The Setup: Building Without All the Pieces
+
+You’ve just joined a fintech team working on a new system to ingest regulatory data. The goal is to transform incoming data into a new platform format and store it securely and compliantly. The architecture is API-driven, and your system is designed to send processed data to a set of storage APIs.
+
+But there’s a hitch: those storage APIs aren’t ready yet. Some are still being developed, others are unstable, and a few are simply inaccessible for testing. You’re building a pipeline, but the final destination doesn’t exist.
+
+So how do you test your system’s ability to process and store data when the storage layer isn’t available?
+
+## 2. Mocking: Simulating the Final Step
+
+This is where API mocking comes into play, not to be confused with API testing. While API testing is about verifying your own APIs, mocking is about simulating external ones so you can test your system in isolation.
+
+In our case, we were mocking the storage APIs that would eventually receive the transformed data. By simulating these endpoints, we could validate our ingestion logic, transformation rules, and integration flows without waiting for the real storage services to be ready.
+
+Mocking allowed us to:
+
+- Test the full ingestion to storage flow.
+- Validate data formats and payload structures.
+- Simulate error conditions and network behaviours.
+- Work in parallel with teams building the actual storage APIs.
+
+## 3. WireMock: Our Mocking Workhorse
+
+To build this simulated environment, we used **WireMock**, an open-source tool that lets you mock HTTP APIs with control.
+
+Here’s how we configured it:
+
+- **Stubbed endpoints**: We mocked endpoints like `/api/docs` to behave like the real storage APIs.
+- **Controlled responses**:
+  - `201 Created` for valid payloads.
+  - `400 Bad Request` for missing or malformed fields.
+
+This setup allowed us to test how our system handled:
+
+- Correctly transformed data.
+- Payloads with missing fields or incorrect formats.
+- Unexpected server errors.
+
+## 4. Left-Shifting Quality: Testing Before It’s Too Late
+
+By mocking the storage APIs early, we were able to left-shift our quality assurance, moving testing earlier in the development cycle. This helped us:
+
+- Catch integration bugs before the real APIs were available.
+- Ensure robustness by simulating failures.
+
+For instance, WireMock could be configured to catch a problem with how a system creates unique IDs for each request. These IDs are meant to be different every time, so the system can keep track of things properly. But in test, WireMock kept returning a “409 Conflict” error, which it can be set up to do if it saw the same ID more than once.
+If we’d waited to test with the real API, we might not have noticed this issue straight away, because the live system may not yet be checking for duplicates yet. WireMock’s strict checks can help spot problem early.
+
+## 5. The Trade-Offs: Mocking vs Reality
+
+Mocking isn’t without its drawbacks:
+
+- Mocks can drift from the real API behaviour if specs change.
+- False positives: Tests may pass against mocks but fail in production due to subtle differences.
+- Maintenance overhead: Keeping mocks aligned with evolving API contracts requires effort.
+
+But the benefits far outweighed the risks. Mocking gave us confidence to build and test early, and when the real APIs would be finally available, our system was already well-prepared.
+
+## 6. Final Thoughts: Mocking as a Strategic Enabler
+
+This experience showed us that mocking isn’t just a temporary fix, it’s a strategic enabler. It allowed us to move quickly, test thoroughly, and deliver quality software even when key components weren’t yet in place.
+
+WireMock proved invaluable. It gave us control, flexibility, and speed. And while it didn’t replace real integration testing, it helped us get there faster and with fewer surprises.