From a bug report to a verified fix

What to prepare

• Download the sample: it contains a JavaScript function, a description of the bug and reference values.
• For your own project, provide the relevant repository or files, the run command and the limits on what may change.
• Describe the reproduction so that another person could trigger the same bug.

The source files use sample data. Replace it with your own once you have the process down.

Ask Octodus to confirm the problem

First, Octodus should check the original scenario. In the sample, a discount of 10 means 10 percent, but the function treats it as a ready-made fraction. The actual result differs from the expected one.

If code execution is not available, ask it to clearly separate analysis from a real run. Do not accept an assumption about behavior as the result of a check that was actually executed.

In the attached sample, the total after discount is calculated incorrectly. Reproduce the bug with the given input. Explain the cause, then make a minimal fix. Do not expand the task with new features. If you could not run the code, say so explicitly.

Check the original and neighboring cases

After the fix, calculate the total again for the order that was wrong. Then check a zero discount, a full discount and an amount with cents.

In a real project, also run its existing checks. Ask for a list of what was run and what remains unverified. This helps you judge how ready the change is in practice.

Check the fixed function against all reference cases in the file. Show the input, the expected result and the actual result. Explain the change in the code and list the limitations this sample function does not cover.

Example result

The key nuance and verification

Changed code and a successful build do not prove the fix. What matters is checking the scenario that used to fail. For money calculations in a real product, rounding rules and how amounts are represented are defined separately; this sample function is no substitute for that part of the design.

Before you use the result

• The cause matches the observed behavior.
• The original scenario now gives the expected result.
• The edge cases named in the task have been checked.
• The report makes clear which checks were run and which were not.

How to repeat this on your own task

Keep the format of the task: context, reproduction, expectation, limits on the change and verification. It works well for your next bugs. To host a small service of your own, move on to the Octo Cloud lesson with Postgres.