beyond the UI

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

@@ -0,0 +1,79 @@
+---
+title: beyond the UI
+date: 2025-09-25T00:00:00Z
+categories:
+- Testing
+- Mocking
+tags:
+- SoftwareEngineering
+- BackendTesting
+- QualityAssurance
+summary: 
+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, `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`.  
+WireMock allowed us to simulate that scenario repeatedly until we resolved the issue.
+
+## 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.