I'm still learning how to write effective test cases, and I'm wondering how experienced developers find edge cases. Do you use a systematic way to think about what might go wrong, or do you mostly discover edge cases while writing and running unit tests?
4 Answers
A useful place to look is around branching logic, especially missing or incomplete else cases. Guard clauses and simpler conditional paths make those assumptions easier to notice. Make sure each meaningful branch has a test, including the paths that represent invalid or unusual input.
Use several sources of information: requirements, user stories, documentation, existing behavior, and discussions with analysts or stakeholders. Legacy code often contains undocumented rules, so inspect the surrounding code and ask what behavior is expected before changing it. Then have another tester or user review the result, since someone who did not write the code is more likely to challenge its assumptions.
Start with the requirements and look for every possible input, boundary, and decision branch. Ask what happens with empty values, zero, negative numbers, very large values, missing data, duplicate data, invalid formats, and unexpected combinations. Writing tests before or alongside the implementation can also expose unclear assumptions.
Exploratory testing is great for finding cases you would not think of while coding. Try using the feature in ways a curious or careless user might, and deliberately break assumptions. When a bug is found, turn it into a regression test so the same problem does not return.
That makes sense. I hadn’t considered the surrounding legacy behavior as part of the test requirements, but it seems like an important source of hidden cases.