Week 7: From Philosophy to Practice

Last week, I learned about building the right mindset for testing, focusing less on “proving success” and more on “finding boundaries.” This week, I finally moved from that philosophy into hands-on practice. My focus was on integration testing in Flutter, especially around the QR scanner journey.

Understanding the Testing Layers More Clearly

I deepened my understanding of the three main testing layers in Flutter:

• Unit testing: Quick checks on small logic.
• Widget testing: Ensuring a widget behaves as expected in isolation.
• Integration testing: Running through the entire user journey.

It became clear that each layer has its role. Unit and widget tests give speed and confidence, but only integration testing can answer: “Does the whole thing work together like a real user would experience it?”

Using testWidgets() for Complete User Flows

One of my “aha” moments this week was realizing that testWidgets() is not just for isolated widget checks, it can also be used to simulate complete user flows. For example, I can:

• Build the MaterialApp inside a test.
• Interact with buttons, text fields, and scanners just like a user would.
• Verify the final UI state after multiple steps.

This helped me bridge the gap between widget and integration testing, since I could test flows step-by-step but still keep control over dependencies using mocks.

I also mapped out the pipeline from QR scanning → validation → database lookup, and thought about where things could break. By testing each layer appropriately, I learned how to cover the system more effectively.

Integration_Test + Mocktail Combo

I also explored Flutter’s integration_test package. I learned that:

• It’s basically an extension of flutter_test, but designed for full-app flows.
• It lets me build the app, interact with widgets, and check results.
• Combined with mocktail, I can inject fake services into the app and fully control what happens after scanning a QR code.

This setup means I can test flows that would be impossible with real dependencies (like simulating a broken database).

Learning to Think Like a Breaker

One big lesson was about the hacker’s mindset. Integration testing isn’t just happy paths, it’s about asking “What if it fails here?” I practiced writing tests that deliberately break the flow:

• What if the QR code is invalid?
• What if the database is unreachable?
• What if the result object comes back empty?

Each of these scenarios pushed me to think beyond “green checkmarks” and more about how gracefully the system fails.

Reflections & Insights

• Unit vs. Widget vs. Integration: each has a role, but integration testing gives the full picture.
• Mocking ≠ fake database: it’s about replacing dependencies at the right level.
• Control inputs/outputs: mocks let me simulate valid, invalid, and error states.
• Tooling matters: integration_test + mocktail is a powerful combo in Flutter.

What’s Coming Up

• Expand scenarios for both Bouncer (attendance) and Usher (prize collection) flows.
• Explore how to automate running integration tests in CI/CD so they’re part of the pipeline.