Example-Driven Development

Examples look like tests that return an object. This little change has quite some implications as the same artifact can be used for testing, exploration or documentation purposes.

YOUTUBE ZR4RUmeZcS4 Glamorous Toolkit Live #3: Example-driven development (2020)

Examples vs. Tests. medium

With Moldable Development we use examples rather than tests. Basically these are unit tests that return a live instance that you can interact with.

Clojure's Clerk credits Smalltalk's Glamours Toolkit for inspiration into live and moldable programming. The Clerk presentation at Splash 2024 suggested that the impact of "live" on the design process needs more collective investigation. video

The eddLivePaper:

NIERSTRASZ, Oscar, CHIŞ, Andrei and GÎRBA, Tudor, 2024. Example-driven development: bridging tests and documentation. 31 August 2024. arxiv . [Accessed 7 November 2024]. Software systems should be explainable, that is, they should help us to answer questions while exploring, developing or using them. Textual documentation is a very weak form of explanation, since it is not causally connected to the code, so easily gets out of date. Tests, on the other hand, are causally connected to code, but they are also a weak form of explanation. Although some tests encode interesting scenarios that answer certain questions about how the system works, most tests don’t make interesting reading. Examples are tests that are also factories for interesting system entities. Instead of simply succeeding or failing, an example returns the object under test so that it can be inspected, or reused to compose further tests. An example is causally connected to the system, is always live and tested, and can be embedded into live documentation. Although technically examples constitute just a small change to the way that to test methods work, their impact is potentially ground-breaking. We show (i) how Example-Driven Development (EDD) enriches TDD with live programming, (ii) how examples can be molded with tiny tools to answer analysis questions, and (iii) how examples can be embedded within live documentation to make a system explainable. arXiv:2409.00514