Episoder
-
It is important that the system behaviors we create as developers are both accurate and precise. These are not the same. One can be: Accurate, but not precise: “Pi is a little over three.” Precise, but not accurate: “Pi is 5.393858303895.” They are not the same but they are related. The level of precision required … Continue reading "TDD and Accuracy vs. Precision"
-
Ideally in TDD, no more than one test is ever failing at any given point in time. This test represents the work that is about to be done but hasn’t yet. Also, this test should not spend a long time in the red. We want the suite to get back to “all green” as quickly … Continue reading "TDD: Keeping Tests Green"
-
Manglende episoder?
-
TDD is a powerful way to develop new code. However, most organizations have significant existing code that was not developed this way. This “legacy code” is often difficult to test because it was not designed to be testable in the first place. In his excellent book, Working Effectively with Legacy Code, Michael Feathers outlines techniques … Continue reading "TDD and Legacy Code"
-
Refactoring is defined by Martin Fowler as “improving the design of existing code.” Refactoring stipulates two things: that behavior does not change, and that the design has been improved. While developers have been “cleaning up” their code from the very early days, Fowler made this a discipline that developers can collaborate within. He defined a … Continue reading "The Value of Refactoring Skills"
-
Abstract classes in languages like Java or C# serve two purposes: they create polymorphism in design, and they are a convenient place to put behavior that is common to all derived classes, avoiding redundancy. But if all behavior in TDD needs to be tested, and if instance behavior implemented in abstract classes cannot be tested … Continue reading "TDD: Testing Adapters for Abstract Classes"
-
TDD depends on a strong connection between the automation of the test suite and the system itself. The suite should record the specification that is implemented in the system, and the connection allows this to be confirmed at any point. The problem is automated tests pass by default. So, if errors creep into the test … Continue reading "Sustainable TDD: Part 3"
-
Project managers have to balance resources. Spending them on one thing means not spending them on another. So, when the team adopts TDD, it is understandable that attention is paid to the level of resource needed to sustain it over time. It’s not uncommon for project managers to notice, as the project grows, that the … Continue reading "Sustainable TDD: Part 2"
-
TDD is typically part of an agile process. This means that we embrace change, that new requirements flow into the team’s work either on a time-boxed pulse, or through some kind of pull system (like Kanban). In TDD, a new requirement always starts out as a new, failing test or “specification.” We write the test … Continue reading "Sustainable TDD: Part 1"
-
This is my 48th post in this series on TDD. I wanted to bring some of this material together and engage with the notion of TDD as a sustainable process. In this posting, I will introduce the topic, and then cover some issues that pertain to sustainability and/or the seeming lack thereof. There are those … Continue reading "TDD as a Sustainable Process: Introduction"
-
In TDD and Code Coverage, we established that code coverage tools do not provide useful project metrics, in and of themselves. In TDD, we don’t use code coverage tools for this purpose because we don’t need to. If all production code is written to satisfy prewritten, failing tests, then by definition, all code is covered. … Continue reading "TDD and Code Coverage Tools"
-
TDD often uses unit tests to drive behavior into the system. However, sometimes acceptance tests are used to do this. When these are automated, this can give us clues as to how to make our work in TDD more reusable. Tools like Fit, Specflow, and Cucumber are all designed to parse some non-technical artifact (such … Continue reading "TDD and Test Invariance"
-
Part of the TDD process consists of writing failing tests before the code that will eventually make them pass. Test-first alone is not TDD per se, but it is a part of it. When tests are written before production code, this has several beneficial effects. This comes from the fact that these tests have the … Continue reading "TDD: Tests are Client Number 1"
-
One controversy in software development is the relative value of strong, static typing (as in compiled languages like Java) vs. dynamic typing (as seen in interpreted languages like JavaScript). No attempt will be made here to engage in this debate, but it is interesting to note the role of TDD in languages that are not … Continue reading "TDD and Dynamically-Typed/Interpreted Languages"
-
In TDD, tests take actions such as Setup, Trigger, and Verify. Each of these pieces must successfully execute in order for the specification to be verified as accurate to the current behavior of the system. If there is an external dependency, the test can become vulnerable to a failure of that entity. For example, If … Continue reading "TDD and Guard Assertions"
-
Unit testing frameworks, which are the most common tools used by developers to conduct TDD, come with pre-made assertions that can be used to verify the behaviors being specified. Typically, these include assertions such as: “areEqual()” (value comparison) “areSame()” (entity comparison) “isNotNull()” “contains()” Developers should not limit themselves to these pre-made assertions. The creation of … Continue reading "TDD and Naming Part 3: Customized Assertions"
-
Tests often establish example values used to compare the behavior of the system with the actual behavior indicated in the requirements. For example, if we had a system behavior that converted a temperature expressed in Fahrenheit to one expressed in Celsius, then the test that specified this might have an assertion along these lines: assertEquals(100, … Continue reading "TDD and Naming: Part 2"
-
TDD is not really a testing activity so much as it is about the creation of an executable specification. Because of this we value different things than testers might. Naming of tests, variables, and the use of well-named customized assertions are examples. Test names are sometimes provided by the tools we use. Many IDE’s will … Continue reading "TDD and Naming: Part 1"
-
TDD, when conducted as a specifying activity, is an aspect of Behavior-Driven Development (BDD). Behavior is what we specify and is what we “drive” into the system using tests. Therefore, when structuring the tests in TDD we can be guided by the language of BDD: Given, When, Then. Given the system is in a known … Continue reading "TDD and Test Anatomy"
-
Developers often remark that the tests may contain the same algorithms that the production code does. This feels like redundancy and makes them wonder if TDD is promoting bad practices. Example: A system that converts Fahrenheit to Celsius. The code would contain something like this: return (F - 32) * 5/9; The test might contain … Continue reading "TDD Replicating Algorithms"
-
When first adopting TDD, developers can run into some roadblocks that seem to indicate that TDD is a difficult process. In truth, some of these problems actually indicate faults in the system architecture. For example, developers will struggle to write unit tests of behavior that is embedded in a user interface, or in stored procedures … Continue reading "TDD and System Architecture"
- Vis mere
