Green Tests and Red Tests
In practice I found that there are times that I want a bit more test coverage than I get from just doing test-first development. When I do test-first development, I always write a failing test first and then I create the implementation to make that failing test pass. As a result, I get by default …
Continue reading “Green Tests and Red Tests”
Read MoreDrive to Testability
There are patterns, things that developers do when writing code that support testability of code and there are anti-patterns, which are things that developers do that lead to writing code that is difficult to test. As a developer, I’ve found it helpful to become aware of some of these testability patterns and anti-patterns that I …
Continue reading “Drive to Testability”
Read MoreSummary of Seven Strategies Series
I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. These posts are filled with practical advice for implementing the nine core practices from Scrum, Extreme Programming, and …
Continue reading “Summary of Seven Strategies Series”
Read MoreUse Accurate Examples
I discussed many benefits of using test-first development over these last eight blog posts. I find many benefits to doing test-first development but one stands out to me to be the biggest benefit and that is that the tests that I write concretize abstract requirements. This makes requirements understandable because they are real and tangible …
Continue reading “Use Accurate Examples”
Read MoreAvoid Over-Specifying Tests
The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code. I am a big advocate of having a complete …
Continue reading “Avoid Over-Specifying Tests”
Read MoreUse Mocks to Test Workflows
Unit testing frameworks are simple but I find them highly valuable. They contain a collection of assertions that I can use to validate a range of values and behaviors in the code that I’m building. I use assertions to verify that values are within bounds, exceptions are called when expected and not called when unexpected, …
Continue reading “Use Mocks to Test Workflows”
Read MoreTest Behaviors, Not Implementations
One of the keys to doing test-first development successfully and having the tests that you create to support you in refactoring code rather than breaking when you refactor code, is to write tests against the behaviors you want to create rather than how you implement those behaviors. This is an important insight but not always …
Continue reading “Test Behaviors, Not Implementations”
Read MoreShow What’s Important
Another aspect of using unit tests as specifications is to clearly show what’s important in each test. We do this primarily by naming things well and calling out generalizations and key concepts in the names of the symbols that we use. Every test has a name but you never call it, the system calls it …
Continue reading “Show What’s Important”
Read MoreUse Helper Methods
What? Helper methods? Whenever I see a class called Helper in code I think that the developer who wrote it wasn’t willing to take the time to discover what objects were really responsible for those behaviors. Although we would like to believe otherwise, in reality, there is no benevolent helper class in the world that …
Continue reading “Use Helper Methods”
Read MoreInstrument Your Tests
Here is the first of seven blog posts based on the section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, called Seven Strategies for Using Tests as Specifications. In this first post, I’ll discuss a technique called instrumentation that I learned from Scott Bain and Amir …
Continue reading “Instrument Your Tests”
Read MoreWhy Practice 7: Specify Behaviors with Tests
Developing software is a complex activity. Having worked with thousands of professional software developers, I recognize that there are many ways to implement any set of requirements and many are equally valid. This is true at least from the computer’s perspective but from the human perspective, we favor software that’s straightforward to understand and modify …
Continue reading “Why Practice 7: Specify Behaviors with Tests”
Read MoreIntroducing TDD to Managers
In my last blog post, I discussed different ways of introducing test-driven development to teams. The bottom line is to give developers an experience of benefiting from doing TDD. Once they see how their tests catch bugs that otherwise would have perhaps escaped and had to be fixed later, and how TDD helps them keep …
Continue reading “Introducing TDD to Managers”
Read MoreCode Coverage
Like most metrics in software development, code coverage can be a good indicator or it can be heavily abused. I know many teams that have a code coverage standard. For example, 80% of their code must be covered by unit tests. The problem with having a standard for the percentage of code coverage is that …
Continue reading “Code Coverage”
Read MoreWhat Makes a Good Test?
Many developers assume they know how to write a good test, but in my experience few developers really do. They test units of code rather than units of behavior and their tests become implementation dependent and break when the code is refactored. Rather than providing a safety net for developers to catch errors when refactoring, …
Continue reading “What Makes a Good Test?”
Read MoreSeven Strategies for Fixing Bugs
Bugs are the bane of the software industry. They can be difficult to find and costly to fix. How we deal with bugs has a big impact on our software development process. We can use bugs to show us ways of improving our process so that similar bugs aren’t created again. Here are seven strategies …
Continue reading “Seven Strategies for Fixing Bugs”
Read MoreTest Driven Documentation
Part of allowing change to happen during development is by building software with engineering practices that support change. The most important of these practices is correctly using unit tests. Tests represent a way to both embody understanding of the system and prove that the system works. Unit tests are really a form of specifications because …
Continue reading “Test Driven Documentation”
Read MoreHow Many Tests Are Enough?
How much code coverage should we have? I say 100%. Do we really need to test getter and setter methods? No and yes. We don’t need to verify the trivial behavior of getters and setters but it can be valuable to have a test for them so that their existence is specified. Likewise, I have …
Continue reading “How Many Tests Are Enough?”
Read More