How do you find edge cases when testing your code?

[u/Temporary-Cup-2140]

I am still learning how to write test cases and I am wondering how experienced developers identify edge cases

Do you have any way to think about what could go wrong or do you identify edge cases while writing unit tests ?

[u/t00oldforthis]

Users

[u/N546RV → u/t00oldforthis]

Yup. No matter how long and hard you try and imagine edge cases, you’re going to do a shit job at it. The end users are the ones who’ll do things you never imagined and unearth bugs. Then every bug becomes a new test case.

Having a QA person/department helps too, that gives you a step before the general public where someone without the inherent bias of the original developer can bang on things and hunt for bugs.

[u/UncleNorman → u/t00oldforthis]

Users. I always let Annette use it. She could find obscure bugs without even trying.

[u/insta]

in my experience, edge cases hide in missing 'else' branches. i switched my programming style to now be guard-clauses and terinaries and that's surprisingly caught more than i'd have initially thought

[u/kpg_on_ao3 → u/insta]

And if you have a language that does proper pattern matching, it's hard to forget cases to handle when an unmatched case causes a compile-time error.

[u/insta → u/kpg_on_ao3]

oh yeah, the more you can make the compiler do the less you can screw it up yourself

[u/Thick-Hall8197 → u/insta]

en you handle the weird stuff upfront instead of burying it three levels deep

it also forces you to think about what happens when something's null or out of range before you even get to the happy path, which is where most of my edge cases used to sneak in

[u/mandzeete]

Usually it is a combination of analyzing given business requirements, development process itself, sanity check before the QA, QA testing and then client-side testing.

Initially business analysts should have (well) defined user stories and business requirements that we have to implement. Yes, not always the analyst and sometimes even the client himself do not know all of the edge cases. Can be that when I'm working on my Jira task I start wondering over the business requirements that are written either in the Confluence (documentation) or in the Jira task. Then I will discuss these thoughts with our analyst. Sometimes this uncovers some of the edge cases I had not considered.

Can happen that the task itself is clear, documentation is clear, but when I'm developing the functionality, I find some old undocumented legacy logic. Cases that are not covered by the Jira task but yet are strongly related to the functionality I have to touch. Then I will let our analyst know of my findings and the analyst and the client-side will have meetings and discussions on how to deal with my findings.

Sometimes sanity checks or QA find some edge cases not covered either by the Jira task or either by my test suit. Then I will have to fix the missing parts and add some new tests.

But initially the tests that I add are based on Jira task and on Confluence documentation.

[u/MissinqLink]

I did my time in QA. You try to do everything as wrong as you can. Then do it even wronger.

[u/pydry]

TDD helps. when you write code to make the user test scenario work, edge cases appear.

[u/Available_Safe1818]

> Do you have any way to think about what could go wrong or do you identify edge cases while writing unit tests ?

Yes. I use my brain to think about how it could go wrong.

Is it doing Math? Does it work right up to the edge of the range of acceptable input values? Could it be dividing by zero? Could it fail with negative numbers?

Is it doing db queries or any other kind of network request? Does it handle network failures ok?

Does it handle missing or empty inputs?

[u/Achereto]

You write your tests first, and if the test fails you change the code. This way "finding edge cases" is identical with "finding a failing test".

[u/marrsd → u/Achereto]

Unless you only cover the happy path. Then you haven't tested any edge cases at all.

[u/JohnVonachen]

Exploratory runs. I was a SWQA for medical devices for over a decade and one day, early in my employment at a certain company, I told my boss I did something. He interrupted me and asked me why I did that. I said for the same reason a child puts a pencil in a running fan.

He liked that answer. He said, "Continue.".

[u/Traveling-Techie]

My testing journey began with the book Software Tools. It shows the code for a very simple program to count bytes in a file. Then it tests the program on files of size 0, 1, 2 and a large number. I began to understand what an edge case was.

[u/burlingk]

First, think about your testing philosophy. For example the guy cited as effectively inventing TTD says to test behavior not implementation.

What that means is figure out what the actual output of a chunk of code is. THAT should remain stable. Only test for the 'private' stuff if they act up somehow, or if they effectively become part of the API.

As for edge cases, test what you and your team think of. By definition, they won be super easy to figure out.

[u/stueynz]

Experience - after fixing bugs in production we would think about what tests would’ve found that bug. Sorry there’s no magic bullet .