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 ATDD with Optional Unit Tests

The idea behind my suggestion is very simple, and it relies heavily on the experience of the developers, which in this case was very high. To be effective, it requires the ability to write outside-in testable code naturally, without the need of a test to drive any class.

Basically, if we have a very good suite of acceptance tests like the one we were building in Team C, any bug in the code would be traceable to a few broken units and always at least one broken acceptance. So, acceptance tests would be the minimum number of tests we could write in order to have the safety network to refactor any part of our code.

So, I suggested, "Why don't we break the dogma of full test coverage and stop enforcing unit tests, as we already have the acceptance umbrella? If we write testable code, what's the problem? If at some point we feel like a class would benefit from a unit test, it will be easy to add. The advantage will be that we...