Here are some things I have learned from Scrum. Cross functional teams are good. Just having them achieves a three to tenfold improvement over a group of people working on several projects at once. And they improve innovation by the team. Time-boxing increases discipline, visibility and the ability to pivot. Small batches are good and … Continue reading "What I have Learned from Scrum"

Most organizations have some type of reporting mechanism allowing customers to alert them to defects they have encountered. Typically, a “trouble ticket” or similar artifact is generated, and someone is assigned the task to 1) locate and then 2) fix the errant code. TDD views this very differently. In TDD, a “defect” is code that … Continue reading "TDD and Reported Defects"

“Refactoring” refers to the discipline of improving the design of existing code without changing its behavior. It is usually thought of as a way to deal with old legacy code that is functional but poorly designed and thus hard to work with. Since TDD focuses on driving new behavior from tests, how would refactoring play … Continue reading "Refactoring Applied to TDD"

Some organizations who have adopted TDD as their development strategy have assumed that they no longer need SAT/QA testers, since the developers are now writing tests. This is a mistake. First, developers do not write the same kinds of tests that testers do. Developers write the tests they need to drive correct behavior into the … Continue reading "TDD does not Replace Traditional Testing"

In TDD, we seek to create granular, unique tests, tests that fail for a single reason only. To achieve this, when testing an entity that has dependencies, a typical way to prevent the test from failing for the wrong reason is to create mocks of those dependencies. A mock can be simply a replacement that … Continue reading "Mocking as a Design Smell"

One aspect of strong design is that separation is created between the various concerns of the system. This adds clarity, promotes re-use, improves cohesion, and in general adds value to the work. It can be difficult to know, however, if one has separated things sufficiently, or perhaps has overdone it. This is one area where … Continue reading "TDD and the Separation of Concerns"

We should consider testing, which is an activity, versus testability, which is a quality of design. If we start with the word “test” itself we note that it is both a noun and a verb. I can say, “I have a test for that behavior,” or I can “test a behavior.” As a noun, it … Continue reading "Testing vs. Testability"

The Open-Closed Principle (Bertrand Myers, Ivar Jacobsen) states, “Software entities (such as classes, modules, and functions) should be open for extension, but closed for modification.” This means that a “good” design will allow for a new behavior to be added to a system without having to change the existing code, or at least to minimize … Continue reading "TDD and the OCP"

The type and nature of the tests that you write in TDD helps you to understand how strongly your system is encapsulated. Everything the system must do, and yet might not, needs a test. Here, “must do” comes from your stakeholders’ requirements, and is therefore connected to business value. The more your tests are about … Continue reading "TDD and Encapsulation"

I mentioned earlier that TDD offers qualitative measurements about production code, namely that a large average fixture size can be used to measure relative coupling in a system. Similarly, tests can reveal whether, and to the extent, that the Single Responsibility Principle has been adhered to. The Single Responsibility Principle states that every class in … Continue reading "TDD and the Single Responsibility Principle"