Book Image

Agile Technical Practices Distilled

By : Pedro M. Santos, Marco Consolaro, Alessandro Di Gioia
Book Image

Agile Technical Practices Distilled

By: Pedro M. Santos, Marco Consolaro, Alessandro Di Gioia

Overview of this book

The number of popular technical practices has grown exponentially in the last few years. Learning the common fundamental software development practices can help you become a better programmer. This book uses the term Agile as a wide umbrella and covers Agile principles and practices, as well as most methodologies associated with it. You’ll begin by discovering how driver-navigator, chess clock, and other techniques used in the pair programming approach introduce discipline while writing code. You’ll then learn to safely change the design of your code using refactoring. While learning these techniques, you’ll also explore various best practices to write efficient tests. The concluding chapters of the book delve deep into the SOLID principles - the five design principles that you can use to make your software more understandable, flexible and maintainable. By the end of the book, you will have discovered new ideas for improving your software design skills, the relationship within your team, and the way your business works.
Table of Contents (31 chapters)
Free Chapter
Section 1
Section 2
Section 3
Section 4
Chapter 21
License: CyberDojo

Outside-In TDD: The London School

Outside-in TDD is also commonly know as the London School of TDD, acceptance test driven development (ATDD) or Mockist TDD. In Outside-In TDD, we use mocks to sketch the design of parts of the system we don't know much about yet.

Contrary to classic TDD, we don't wait to create a mess to extract sub-components; we use mocks to sketch them as soon as we write a test. Whereas in classic TDD, most design decisions happened in the refactoring phase, in Outside-In TDD, the design decisions about public interfaces happen in the red stage.

Here, the concept of responsibility becomes key. Identifying the different responsibilities gives us an idea of the kind of collaboration we might need. There is no need to implement the sub-module in this stage, however, because we can stub it and fake its behavior for our test.

This operation is a crucial design decision in itself, because what we are doing here is designing the public interface of...