King Tut architecture: Pyramids, patterns, and tests
What if we considered Mike Cohn's Testing Pyramid a strong statement about application architecture, not a test ratio edict? Could we explicitly design with testability in mind? Should we? What are the real benefits of popular approaches from the past decade, such as TDD, IoC, AOP, and MVx? Gary Pedretti explains how to bring all of these approaches together in a stable, rock-solid whole.
|Talk Title||King Tut architecture: Pyramids, patterns, and tests|
|Conference||O’Reilly Software Architecture Conference|
|Conf Tag||Engineering the Future of Software|
|Location||San Francisco, California|
|Date||November 14-16, 2016|
Mike Cohn introduced the Testing Pyramid in his 2009 book, Succeeding with Agile, as a model for thinking about tests and test automation (focus, ROI, TCO, etc.) when developing a software product. It’s been a powerful visual for guiding teams to craft test suites that are sustainable and effective, regardless of whether they automate or not. But what if we thought about the Testing Pyramid as application design or architectural guidance? Building a product that is well covered by tests, in the ratios described in the Testing Pyramid, requires specific designs and architecture. Gary Pedretti covers modern techniques and patterns that allow for architecture and development to be guided by the Testing Pyramid and addresses the “Am I only doing this for testability, not for value delivered?” question. You’ll leave with new ways to think about the Testing Pyramid, new patterns for developing a well-tested application, and new ways for architects, testers, and coders to work in a truly cross-functional Agile team.