Liz Keogh shows why conversations are the most important aspect of BDD, how examples can help you discover things early, and why discovery is an inevitable part of software development.
Philip Japikse discusses and demoes doing BDD with Context Specifications, then using MSpec to transform those specification into TDD code.
John Davies examines Visa’s architecture and shows how major enterprises have architected very complex integrations incorporating Hadoop, memcached, Ruby on Rails, and many others to deliver innovative technology solutions. John explains how the platform architecture and technologies -- integrated and invented -- must be reliable and able to massively scale.
James Kovacs explains how to use TDD and BDD to focus the architectural efforts on the high-value areas of the code in order to obtain just-in-time software architecture.
James Kovacs discusses using TDD and BDD to avoid complexity and creating evolving architectures where convention is emphasized over configuration.
Tom Sulston explains how to manage systems with Cucumber and Puppet based on BDD principles, including practical tricks and pitfalls. The session demoes using those tools.
Ben Hall shows how Ruby testing tools can help with .NET and ASP.NET development and takes a look at RSpec, Webrat, Cucumber, Selenium and others. Also: a peek at using IronRuby for testing .NET apps.
Domain Driven Design (DDD) is about evolving a shared model of the domain letting the domain model drive the design. BDD is about establishing a shared understanding of “done” working from the outside in until you get there. DDD enables the use of BDD effectively creating software and BDD helps structure the conversations for DDD.
In this talk from FutureRuby, Joseph Wilk gives an introduction to the BDD framework Cucumber and gives valuable tips for getting it adopted and used by customers and developers.
In this talk, Dan contrasts the traditional top-down and bottom-up approaches with a proven "outside-in" approach based on real life experience - engaging with and listening to our stakeholders. He shows how this can allow us to stay firmly on track, leading to clean code and effective design that provides maximum value to our stakeholders, not just the famous Scrum Product Owner