Write tests for code that has none
Most projects have a corner nobody dares to touch because it has no tests. Here is how to have Gravity write them, check that they pass and keep you in charge of what they assert.
Every codebase has a class that everyone avoids. It works, nobody remembers why, and there are no tests, so every change is a risk. Writing tests for existing code is slow, repetitive work that depends on reading the code closely. That makes it a good match for an agent, as long as you stay in charge of what the tests are allowed to claim.
Pick one small target
Do not ask for tests for the whole solution. Choose one class with clear inputs and outputs, such as a price calculator, a validator or a parser. A small target gives you a result you can read in a few minutes.
Say how the tests should look
Write unit tests for PriceCalculator in the existing test project.
Use the same test framework and naming style as the other tests.
Cover normal cases, boundaries and invalid input. Do not change PriceCalculator.
Then run dotnet test.Three details in that request matter. "Use the same framework and style" keeps the new tests consistent with your project. "Do not change PriceCalculator" protects the code under test. Finishing with dotnet test turns the answer into something that has actually been run.
Read what the tests assert
This is the step that cannot be skipped. A test that passes is not necessarily a test that is right. When the code has a bug, an agent that only reads the code can write a test that locks the bug in. In Review mode each new file arrives with a preview. For every test, ask yourself whether the expected value is what the business wants, not just what the code returns today.
Let it run, then ask about the gaps
Gravity runs the tests and, if some fail because of a mistake in the test itself, fixes the test and runs again. When all of them pass, ask the follow-up questions:
- Which branches of this class are still not covered?
- Are there inputs that make it throw an exception, and is that intended?
Surprising answers here are often the real value of the exercise. A boundary that behaves strangely is a bug you found before a customer did.
Make it a habit
Once a class has tests, it is safe to refactor. That is why this workflow pairs well with the refactoring guide: write the tests first, then let Gravity change the code while the tests tell you whether anything broke.
Gravity is free to download with an account. Choose the class you trust the least and give it a safety net.