GeeCON Prague 2018: Thomas Sundberg

### Overview In this talk from GeeCON Prague 2018, Thomas Sundberg, an independent developer from Stockholm, addresses the challenge of building a testable software architecture while ensuring developers first understand what problem they need to solve. Sundberg defines done as working software in production and argues that an effective test suite must balance three properties: confidence that the software works, high speed (short feedback loops), and low maintenance cost. He demonstrates how Behavior-Driven Development (BDD), collaborative specification techniques, and architectural patterns like hexagonal architecture (ports and adapters) allow teams to use a single business-readable specification across multiple testing layers.

### Key Topics - **Bridging the Communication Gap**: Teams frequently fail to deliver correct software due to miscommunication. Collaborative discovery practices, such as the "Three Amigos" (developers, testers, and product owners/business analysts), help surface knowledge across different quadrants, especially uncovering the "danger zone" of unknown unknowns. - **Example Mapping and Concrete Examples**: Abstract requirements are difficult to parse; concrete examples written using techniques like example mapping allow teams to validate rules and questions before formulating them into living documentation. - **Living Documentation with Gherkin**: Writing scenarios in Gherkin (`Given`, `When`, `Then`) allows product owners, testers, and developers to review and criticize acceptance criteria, avoiding unreadable raw unit test code. - **The Agile Testing Pyramid and Testing Iceberg**: Testing through the user interface provides confidence but suffers from slow execution, high costs, and poor diagnosis precision. Unit and model-level tests offer high execution speed and precise diagnostics. Teams should strive to push tests down to faster layers while maintaining confidence. - **Hexagonal Architecture (Ports and Adapters)**: Proposed by Alistair Cockburn, this architectural style keeps domain models free from external infrastructure and transport concerns (such as web frameworks or databases), making it possible to execute business scenarios through multiple entry points.

### Technical Details Sundberg walks through an implementation using Java, Gradle, Cucumber, and Selenium WebDriver for a simple note-taking application. - **Step Definitions as Simple Translators**: Step definitions map Gherkin steps to code and should act strictly as thin translators (one or two lines) that delegate directly to helper abstractions rather than hardcoding UI automation or domain calls. - **Abstraction Layer via Helper Classes**: Sundberg introduces a helper interface with two implementations: `InMemoryNoteHelper` and `BrowserNoteHelper`. A system property (e.g., `-Dbrowser=true`) decides at runtime which helper executes the scenario. - **Dual Execution Profiles**: In-memory execution connects directly to domain repositories, running in under one second. The Selenium browser-driven test starts the embedded server (e.g., using Spark framework on port 4567) and opens a real browser to exercise the UI and background JavaScript, taking around 4–5 seconds. While too slow for every local build, the UI test verifies server startup and wiring in CI pipelines.

### Takeaways Automated testing without a proper understanding of the core problem is wasted effort. Adopting BDD enables teams to specify behavior collaboratively using concrete examples. By decoupling core business logic via hexagonal architecture and maintaining thin translation layers in test suites, developers can execute identical acceptance criteria both in memory for fast local feedback and via full-stack browser automation for end-to-end confidence.