From red to green: fixing failing .NET tests with Gravity
Let Gravity run dotnet test, read the failures, edit the code and run the tests again, while you stay in control with Review mode.
A failing test run is a good job for an agent. The loop is mechanical: run the tests, read the failures, find the code, change it, run the tests again. Gravity can run that loop for you, and because the shell agent has a dedicated dotnet helper, it does it with the same commands you would type.
Start from a known state
Make sure your working tree is committed or stashed. If the agent changes something you disagree with, you want a clean way back. The Git helper in Gravity can show you the status and the diff at any time.
Ask for the outcome
Run dotnet test. For each failing test, find the cause in the production
code, fix it without changing the test, and run the tests again until they pass.The sentence "without changing the test" matters. Without it, the quickest way to turn a test green is to edit the test. Tell the agent which side of the contract is allowed to move.
What happens next
- The planner creates the plan: run the tests, read the failures, edit, run again, verify.
- The shell agent runs dotnet test and returns the output.
- The file agent reads the failing test and the production code it exercises, using search to find the right files.
- The edit is applied as a diff. In Review mode you see it first.
- The tests run again. If something still fails, Gravity retries and replans.
Every step appears in the chat as an expandable tool-call card, with the command or parameters and the result. If you want to know why a change was made, open the card.
Keep the loop bounded
Gravity limits the number of reasoning iterations per task. The default is 25 steps and you can change it in the advanced settings. A bound is useful: if the agent cannot fix a test in a reasonable number of attempts, it is more helpful to get the failure report than to let it keep guessing. You can also press Stop at any time to cancel a running task.
Ask for tests too
The same approach works in the other direction. Ask Gravity to add tests for a class that has none, to run them and to report which ones fail. Failures in new tests often point at real bugs in the code under test, which you can then ask Gravity to fix with the same prompt as above.
Write unit tests for OrderCalculator in the Tests project, covering empty
orders, discounts and rounding. Run them and tell me which ones fail.Review before you merge
An agent's green test run is evidence, not proof. Read the final diff, run the complete suite on your machine and look especially at any changed condition or removed check. Gravity shows its work so this review stays quick.
Gravity is free to download with an account. Try it on a branch with a few failing tests and see how the loop feels.