What TestSprite Taught Me About Testing Concurrency Bugs in FlowGuard AI

Allfridho Saragi — Mon, 26 Oct 2026 20:11:02 +0000

A Passing API Response Doesn't Always Mean Correct Behavior

Imagine two refund requests arriving at almost the same time.

Both requests read the same state. Both believe the refund hasn't been processed yet. Both proceed.

Without proper concurrency protection, one logical refund operation could produce two committed side effects.

This is one of the engineering problems that inspired me to build FlowGuard AI, my project for TestSprite Hackathon Season 4.

I wanted to explore an important question:

What if our code works, but the business rule it is supposed to protect fails?

FlowGuard AI was built to help developers investigate these risks through business-rule analysis and controlled verification.

But building the application also taught me another lesson: a reliability-focused product needs a reliable development and testing workflow.

That's where TestSprite became an important part of my journey.

How FlowGuard AI Works

FlowGuard AI is a browser-based behavioral-risk analysis and verification playground.

The application helps developers investigate code snippets and public GitHub pull requests against business requirements.

It uses three analysis stages:

1. Requirement Analyst

Extracts important business invariants and expected behavior from the requirements provided by developers.

2. Risk Hunter

Examines the available code and highlights potential paths where those invariants might be violated.

3. Verification Planner

Proposes test assertions and verification scenarios that developers can use to investigate the potential problems.

One of the most important principles behind FlowGuard AI is:

A potential risk is not the same as a verified bug.

That's why external code analysis findings are explicitly labeled POTENTIAL.

The application does not execute arbitrary third-party GitHub code. Its Verification Lab uses controlled, first-party synthetic fixtures.

Demonstrating a Concurrency Problem

The Verification Lab includes two refund implementations.

In the deliberately vulnerable simulation:

Concurrent refund attempts: 2
Committed side effects: 2
Expected maximum: 1
Result: VERIFIED_FAIL

In the corrected simulation:

Concurrent refund attempts: 2
Committed side effects: 1
Expected maximum: 1
Result: VERIFIED_PASS

These demonstrations use synthetic, in-memory fixtures rather than real banking transactions.

They illustrate why testing business invariants matters, especially when concurrency and asynchronous operations are involved.

How TestSprite Helped Improve My Development Workflow

One of the most valuable experiences during this hackathon was integrating TestSprite with GitHub pull requests.

What I really appreciated was the ability to connect automated testing with actual code changes.

Instead of treating testing as something to perform only at the end of development, I could use TestSprite's automated feedback as part of the development workflow.

For me, this made testing feel more structured and meaningful.

1. Automated Testing Connected to GitHub

TestSprite's GitHub integration was one of the features I appreciated most.

Having automated test results associated with a pull request made it easier to connect development changes with verification.

It encouraged me to pay closer attention to how the application behaved after each iteration.

I think this is particularly valuable for developers who want automated quality checks to become part of their everyday workflow.

2. Feedback That Encouraged Real Improvements

During an intermediate execution on FlowGuard AI's pull request #14, TestSprite reported:

96 Passed — 0 Failed — 1 Blocked

The blocked case concerned keyboard navigation and user feedback.

Instead of treating the result as a complete success, I investigated the application's accessibility and interaction behavior.

This led to improvements involving keyboard focus management, form interactions, and feedback for users navigating the application.

What I appreciated most was that TestSprite's feedback encouraged further investigation.

Testing wasn't just about collecting passing results. It became part of improving the actual product.

3. Quality Gates That Encourage Better Engineering

Another TestSprite capability I appreciated was its integration with GitHub's required checks.

A blocked test shouldn't automatically be considered a successful test.

Connecting automated testing with pull request merge requirements helps encourage developers to investigate unresolved results before merging.

For my project, this supported a more disciplined approach to software verification.

After further development and testing, the final head of PR #14 achieved:

97 PASSED ✅

0 FAILED ✅

0 BLOCKED ✅

Seeing all 97 TestSprite tests pass on the final pull request commit was one of the most rewarding moments of the hackathon.

The successful official TestSprite V3 execution was associated with the final PR head before merging.

Official TestSprite Result:

https://www.testsprite.com/dashboard-v3/o/28a6d5ec-2a40-54eb-9bf6-0c87db224fde/projects/570eab99-607a-49fa-96b2-fe5ef724f2d9/execution/901e7027-1c4a-477f-adc9-ca0d17b16635

Verified GitHub Pull Request:

https://github.com/allfridhosaragii/FlowGuard-AI/pull/14

Independent Testing Made the Project Stronger

Alongside TestSprite, I used GitHub Actions to run independent automated tests.

After the final pull request was merged, the project successfully completed:

✅ 118/118 Vitest tests passed

✅ 70/70 Playwright Chromium tests passed

These results provided additional evidence for the tested application.

Of course, passing automated tests does not guarantee that software is completely free of bugs.

But having multiple verification methods helps developers better understand which behaviors have been tested.

Post-merge GitHub Actions evidence:

https://github.com/allfridhosaragii/FlowGuard-AI/actions/runs/40273469302

What I Loved Most About TestSprite

After using TestSprite during Hackathon Season 4, several features stood out to me.

Automated Pull Request Testing

I appreciated how TestSprite brought automated verification into the GitHub development workflow.

Clear Test Results

The distinction between Passed, Failed, and Blocked encouraged me to interpret testing results more carefully.

Quality-Focused Development

The earlier blocked case encouraged investigation and improvements to keyboard accessibility.

GitHub Integration

Connecting automated testing with pull request checks made quality verification part of the development process.

Verifiable Evidence

Being able to connect test results with a specific pull request and tested commit made it easier to explain what had actually been verified.

For someone developing a reliability-focused project like FlowGuard AI, these capabilities were especially meaningful.

My Feedback: Making TestSprite Even Better

My experience with TestSprite throughout this hackathon was positive.

I genuinely appreciated how its automated testing workflow helped me pay more attention to verification, accessibility, and software quality.

If I could suggest one improvement, it would be even richer diagnostics for blocked browser tests.

Additional execution traces, screenshots, environment information, and clearer explanations of where a scenario stopped could make debugging easier.

When a browser test becomes blocked, developers sometimes need to investigate whether the issue is related to application behavior, test configuration, or the testing environment.

More detailed diagnostic information would help developers investigate those possibilities more efficiently.

I believe this would make an already valuable testing workflow even more useful.

More Than Just 97 Passing Tests

Looking back on this journey, I realized that the most valuable result wasn't simply achieving a green testing dashboard.

It was the development process behind it.

I built an application.

I integrated automated testing.

I encountered a blocked test.

I investigated the application.

I made improvements.

And I continued verifying the results.

This is what made TestSprite valuable to me: it helped make verification a meaningful part of the development process.

The experience reinforced something I want to carry into future projects:

Good software engineering isn't only about writing code that works. It's about understanding what the code must guarantee and collecting evidence that those guarantees hold.

Thank You, TestSprite!

I want to express my appreciation to the TestSprite team for organizing Hackathon Season 4.

This hackathon gave me an opportunity to build a real project, explore software reliability problems, improve my engineering workflow, and learn more about automated testing.

I'm grateful for the tools, the challenge, and the opportunity to improve.

Achieving 97/97 passing TestSprite tests on FlowGuard AI's final pull request was an exciting milestone.

But more importantly, the experience helped reinforce a testing mindset that I want to continue developing.

Thank you, TestSprite, for being part of this journey!