Ladon Philosophy

We and our users agree: software is complicated. Sadly, our agreements often end there - we can rarely find common ground on fundamentals such as what it does, how it works, and even whether it works.

Enter Ladon, which identifies and addresses limitations in how we construct and maintain our software. These limitations reduce our ability to reason about and work with the software we create, causing countless quality issues and functional deficiencies in our software.

The Symptoms

Consider the wealth of flaws and issues that define the modern software experience for users:

• Bugs
• Security vulnerabilities and breaches
• Undocumented and confusing UX
• Rapid, unpredictable, and often significant UX-breaking changes

The Root Cause

We are responsible for writing not only testable code, but also testable products. If we create software and we cannot prove its quality and correctness in end-to-end contexts, then we have not written good software, and we cannot claim we have solved the problem we are trying to address. As evidenced by Google's advice, we aim to allocate a mere 10% of our testing strategy to testing our complete product. No wonder we have bad software!

The Problem We Must Solve

As Google mentions in its advice, end-to-end (E2E) testing is hard because of some inherent challenges:

• E2E tests are slow
• E2E tests are unreliable
• E2E tests do not isolate failures

What we don't see in that blog post is an attempt at solving these challenges; instead, the it simply claims that "E2E is too hard, do unit tests instead." However, unit tests and E2E tests are not alternatives, they are complements. Each serves its own purpose, and tests the software at a different scope, looking for different types of issues.

Ultimately, the problem we must solve is our broken mindset. The symptoms mentioned above persist, so we must continue to improve how we test our products.

Our Solution

Ladon is built on a single core premise: as engineers, we must attempt to resolve these difficulties, rather than giving up and shying away from them. E2E testing seems like a really good idea, and Ladon is not willing to give up on that idea just because no one has figured it out yet. In order to establish a fast, reliable, impactful approach to end-to-end testing, Ladon learns from what makes unit testing work so well: code integration and surrounding structure.

When a unit test fails, we can triage it quickly and effectively because it binds directly to the code it is testing. The code establishes structure that helps us reason about what happened and why. In the E2E case, we typically bind to the product, not the code! When the code changes, the product does as well; in contrast, the E2E test becomes inaccurate because it is testing against a now-outdated specification of how it thinks the product is structured.

Ladon tries to make E2E tests more like unit tests. It consists of two tools that allow us to achieve this goal:

• Modeler allows you to code "models" of your software, which can be integrated with lower level code and define system-level rules and structures
• Automator - allows you to write "automations" that consume your software via scripted interaction with your models

---

Next: read the design overview. Feeling bold? Skip to the "writing Ladon" overview.