• 

  Home Page

Inspiration

In competitive programming and hacking-style contests, most wrong answers don’t come from bad algorithms. They come from missed edge cases.

Developers usually test a few normal inputs, feel confident, and submit. When a solution fails, it’s almost always because of a hidden assumption: boundary conditions, degenerate inputs, adversarial ordering, or worst-case structures that were never tested.

We were inspired to build EdgeCase Engine to attack that exact problem. Instead of helping users write solutions, we wanted to help them validate correctness by systematically generating the inputs that most often break real solutions.

What it does

EdgeCase Engine is a web app that generates, organizes, and reuses deterministic edge-case test inputs for algorithmic problems.

Users define a problem using constraints, tags, and input structure (arrays, strings, graphs, etc.). The engine then generates a small, curated set of edge cases, where each testcase targets a specific failure pattern such as:

boundary conditions degenerate inputs adversarial ordering disconnected graph structures performance-heavy cases

All generated edge cases can be saved, tagged, searched, and exported for reuse in future problems.

How we built it

EdgeCase Engine is built as a web application with:

a frontend for defining problems and triggering generation a backend API that runs a template-based deterministic generator MongoDB as the persistence layer for problems and testcases

Instead of random fuzzing or AI models, we used hand-designed templates tied to known bug patterns. Given the same problem definition and seed, the engine always produces the same outputs, making debugging and regression testing possible.

MongoDB was a natural fit because each problem stores flexible, evolving data like constraints, tags, generator configuration, and generated testcases. The document model allowed us to iterate quickly without rigid schemas.

Challenges we ran into

One major challenge was avoiding noise. Early versions of the generator produced too many testcases, including duplicates, which made the output feel random and unhelpful.

We also had to ensure that every testcase served a clear purpose. An edge case is only useful if the user understands why it exists, so we focused heavily on categorization and intent.

Finally, we had to resist over-automation. It was tempting to make the tool “solve” problems, but we intentionally kept it focused on exposing incorrect assumptions, not replacing human reasoning.

Accomplishments that we're proud of

Building a deterministic generator that produces reproducible edge cases Designing a system that selects representative testcases instead of brute-force output Creating a reusable edge-case library rather than one-off tests Keeping the tool explainable, lightweight, and developer-focused

What we learned

We learned that correctness is often about coverage, not complexity.

A small number of well-chosen edge cases can be more powerful than dozens of random inputs. Deterministic systems build more trust than opaque ones, and tools for hackers should reduce mental load, not add to it.

What's next for EdgeCase Engine

Next, we want to:

add community-shared edge-case templates support importing problem statements directly build lightweight analytics on common failure patterns expand coverage for more problem types

Long-term, we want EdgeCase Engine to become a tool hackers keep open while coding — not to solve problems for them, but to make sure the solutions they write are actually correct.

Built With

• api
• express.js
• javascript
• json
• mongodb
• node.js
• react
• restful