0
Debug a Real Bug with AI: From Reproduction to Regression Test
An original worked debugging guide: isolate an input-conversion bug, make a small fix, and protect the intended behavior with meaningful tests.
0 comments10 views3 steps
Comments
An original worked debugging guide: isolate an input-conversion bug, make a small fix, and protect the intended behavior with meaningful tests.
Act as my debugging partner for a fictional JavaScript shopping-list app. A user reports that adding two items sometimes produces 23 instead of 5. The simplified calculation is const total = firstInput.value + secondInput.value, and the two input fields contain 2 and 3. Start by explaining what evidence you need and what this snippet actually establishes.
Help me write the smallest reproduction and identify one likely cause. Separate observation from hypothesis, avoid rewriting the entire app, and do not claim you ran the code. State the expected result, the actual reported result, and the assumption your investigation will test.
The expected result is the numeric total 5; the reported result is 23. In the supplied expression, ordinary HTML input values are strings. Adding the strings '2' and '3' joins their text, which explains this exact symptom. That gives us a strong explanation for the simplified example, but it does not establish that every 'wrong total' report in the full app has the same cause.
A minimal reproduction is to evaluate const a = '2'; const b = '3'; const total = a + b; and inspect both the result and the types. For the real page, inspect the values and their types at the point the calculation runs, preferably using the debugger rather than adding persistent logs. Compare a single-digit example with a decimal example to confirm the same conversion boundary is involved.
The reusable investigation prompt is: Given this input, expression, expected result, and observed result, identify the earliest point where the data type disagrees with the intended operation. Propose one discriminating check before changing code. Here, confirming that both operands are strings would support the diagnosis; discovering already-converted numeric operands would require looking elsewhere.
Design a small helper for converting those two text fields into a numeric sum. For this exercise, accept finite base-10 decimal numbers with an optional leading plus or minus sign, such as 2, -3, 2.5, and .5. Reject empty text, trailing decimal points, hexadecimal notation, exponent notation, and text such as 2kg.
Explain why replacing the expression with Number(firstInput.value) + Number(secondInput.value) is incomplete under that policy. Give a compact implementation I can adapt, and distinguish an invalid field from a valid field containing zero.
Conversion needs an explicit input policy. Number('') and Number(' ') produce zero, which would make an untouched field look like a valid quantity; Number('0x10') also accepts a form we excluded. Likewise, parseInt('2kg', 10) can accept a numeric prefix and discard the trailing text. Validate the whole trimmed string before converting it.
For this exercise, a compact implementation is: function parseAmount(raw) { const text = raw.trim(); if (!/^[+-]?(?:\d+(?:\.\d+)?|\.\d+)$/.test(text)) return { ok: false, error: 'Enter a decimal number' }; const value = Number(text); return Number.isFinite(value) ? { ok: true, value } : { ok: false, error: 'Number is outside the supported range' }; }. Parse the fields separately and calculate the sum only if both results have ok: true; also check that the resulting sum is finite.
The text '0' is valid and yields zero; an empty string is invalid and needs a field-level message. This helper uses ordinary JavaScript floating-point numbers, so it is not an exact-decimal currency implementation. If the app later handles money, define its currency and rounding requirements before choosing a representation rather than quietly treating this exercise as a financial calculator.
Give me a focused test plan for the helper and the original screen interaction. Cover the original bug, valid zero, whitespace, malformed input, and a sum that cannot be represented as a finite number. Each test should check an observable requirement rather than copy the implementation.
Also write a short change summary for a reviewer. Clearly distinguish expected results from tests actually executed in this conversation, and explain what remains outside the scope of this narrow fix.
The core regression case supplies '2' and '3' and expects numeric 5. Add '0' and '3' to protect valid zero, ' 2 ' and '3' to confirm the trimming policy, and '2.5' with '.5' to expect 3. Empty text, whitespace-only text, '2kg', '0x10', '2.', and '1e3' should produce an invalid-field result under the stated rules. Those checks describe the contract independently of the chosen regular expression.
To exercise sum overflow, generate a decimal string consisting of '1' followed by 308 zeros and use it in both fields. Each parsed value is finite, but the sum exceeds the finite number range and must trigger the sum-level error. On the screen, verify that invalid input displays a useful message, preserves the entered text, and does not replace the total with a misleading zero. These are expected behaviors for the proposed checks; no application tests have been run here.
A reviewer summary could read: Convert validated decimal text to numbers before adding shopping-list quantities. The previous expression concatenated two input strings; the new path rejects missing or malformed values and handles a non-finite sum. Validation should cover the original 2-plus-3 reproduction and the documented input boundaries. Localization, exact currency arithmetic, and broader app refactoring remain separate requirements.
Comments 0
Share how you would use this prompt or suggest a useful improvement.