Keith Braithwaite conducts a tutorial class on TDD based on the following technique: Add a test, See it fail, Make all tests pass, Refactor, and Repeat until done.
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.
Jason Gorman presents how developers can learn TDD to the point of transforming the knowledge acquired into habits by exercising a number of practices over a period of 4-6 months followed by evaluation done by fellow co-workers.
Nat Pryce exemplifies how he dealt with flickering, false positives, slow, and messy tests appearing in asynchronous testing when trying to perform end-to-end testing.
John Hughes shows how to explore the possible bugs of a code by creating a series of tests in Erlang and using multiple test frameworks, discovering the faults through successive tests and evaluating the frameworks while doing it.
Robert C. Martin, during his keynote at QCon London 2010, tried to figure out why there is so much bad code written. He offers advice on writing good code talking about a bad code example, Boy Scout rule, functions, arguments, craftsmanship, TDD, continuous integration, pairing, small cycles, patterns, engineering, certification, and other elements contributing to qualitative code.
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.
Steve Freeman offers advice on writing good tests that make development easier avoiding adding dead weight code that is hard to maintain. Freeman covers the following areas: test readability, complex test data, test diagnostics, and test flexibility.
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.