TestSprite and Claude: turn recorded failures into a repair-and-retest loop

Establish the starting test result

The February demonstration connects TestSprite to Claude through MCP and tests BibleFlow, which Luke says he shipped without testing. The published description reports 16 tests run and all 16 failing. That is the starting state for the repair sequence, not a complete inventory of every possible defect in the app.

The retained product link is https://www.testsprite.com/?via=luke. The source advertises 400 free credits, an offer from the publication context rather than a verified current entitlement. Use the app introduction at 0:35 and failed-test section at 3:45 to understand the tested build and its actual reports.

1. Identify the app version and the behaviour the tests cover.
2. Keep the original failing results before asking for repairs.
3. Inspect the failure details so the repair request targets a specific observed problem.

Connect the repair to the evidence

Claude’s repair section begins at 4:45, followed by AI testing videos at 6:00. The description says Claude analyses the failures and fixes critical issues. Use the reports and frontend recordings to compare what was attempted, what failed and what the code change is intended to correct.

A generated test video is particularly useful when a failure concerns navigation or a visible interaction. Read it alongside the test’s expected result instead of treating movement on screen as proof that the whole application works.

1. Give Claude the relevant failure evidence and expected behaviour.
2. Inspect the resulting change against the reported issue.
3. Use the testing video to locate the point where actual and expected behaviour diverge.

Count the rerun honestly before deployment

The description reports six tests passing after the rerun. It does not say the entire 16-test suite becomes green. Keep the remaining unresolved tests visible; the title’s “every bug” and the description’s self-healing language should not overwrite that concrete count.

Deployment is covered from 7:15. Before treating a repaired version as ready, inspect which checks now pass, which still fail and whether the important user path is covered. This companion describes the recorded repair loop, not a new test of BibleFlow or proof of an unattended CI/CD service operating reliably overnight.

The takeaway

The demonstrated improvement is six passing tests after an initially all-failing run. Use the remaining results to guide the next repair.