Tag Archives: Design

Why Should We Do Test-Driven Development? Part Four

Posted on by

When a team practices the discipline of test-driven development, it gives them a new power.  When all of the code’s intentions are preserved by the tests, it allows anyone to change any of the code at any time without breaking it.  As far as I know, there is no other way to do this.  What this means to a developer, is that it is possible to revise existing code whenever it needs to be revised.

The practice of revising existing code without changing its intended behavior is called “Refactoring.”  Over the last 15 years or so, I have witnessed the power of refactoring.  One of the most obvious things that refactoring does is that it helps us remove duplicated code from the system.  This not only makes future change easier, it reduces the lines of code that must be maintained.  By way of refactoring, TDD makes the code itself more agile.  Refactoring has become such a major tool in my practice, that I now wonder if I have written more lines of code than I have deleted in the last five years.  When I come to a system that is completely covered by tests, I am able to remove duplicated code.  This allows me to remove duplicated tests as well. If a system hasn’t been refactored well, I may end up removing more lines of code because of duplication, than I add when I make a new features.

Refactoring improves the internal design by allowing us to do simple things like renaming variables and methods.  I do realize that some of this can be done using modern refactoring tools without TDD, but there are many cases where dynamic types, strings and reflection cannot be determined by a refactoring tool.  You can break a system by renaming when you don’t have tests.

When I first switched to TDD, this power was a game changer.  For the first part of my career, I had to be very, very careful not to change things.  I looked for ways to not touch things in order to improve my ability to finish a new feature faster.  When a design is good, this can still be a good thing to do, but the fear of change usually leads to system deterioration.  Doesn’t it make sense that we learn more as we spend more time in a problem domain?  Don’t you think that if we know more about a problem domain that it would help us design code that matches that domain better?  Then it only makes sense that we will have better ideas for the code’s design after some of the code has already been developed.  The more experience we gain, the more we see how the design could be improved.  TDD gives you the power to make those improvements.

As I mentioned in the previous article in this series, TDD also helps us design better interfaces because it usually forces us to build something that we can imagine.  This helps us to make small, single-responsibility classes.  That’s the “S” in the SOLID principles. In fact, TDD tends to naturally help us to follow most of those principles.  We tend to make small classes, so they tend to be closely related to a single feature and that makes them more closed to change.  That’s the Open Closed Principle.  We also tend to inject the objects because they are much easier to test that way.  That causes us to reverse the dependencies naturally.  That’s the Dependency Inversion Principle.  When we near a boundary, it becomes much harder to test, so we tend to use interfaces that represent the difficult boundaries to test.  That’s the Interface Segregation Principle.  Interesting isn’t it?

Have you ever considered how you might make a spider web?  I’m going to guess that it wouldn’t be trivial, especially if I gave you constraints that actual spiders have, such as where certain objects are placed, how much wind there is and so on.  Now what if I was able to reduce your brain to the size of a spider’s and then ask you to make those same webs?

The reason I ask such a strange question, is that it seems possible that some things we do can be done with less mental energy if we use simple, repeatable disciplines.  TDD appears to be a discipline like that.  When we practice it, it helps us to naturally produce beautiful code in a variety of unusual circumstances, much like a spider is able to make a beautiful and functional web in many different places and conditions.

Why Should We Do Test-Driven Development? Part Three

Posted on by
Reply

In part one of this series I discussed what I believe is the most important reason to do TDD and that is for programmers to have a way to preserve their intentions.  In the second part, I explain the benefit that TDD gives a development team in the area of documentation.  In this part, I would like to discuss the effect that TDD tends to have on software design.

When we discipline ourselves to consider the end result of our programming efforts, it focuses our minds on the reason that the software is being made.  Our thinking shifts from the effect, to the cause.  By forcing ourselves to document the test first, we must do enough investigation and thinking to determine what is being requested.  One way that this kind of thinking improves code design, is that it ensures that the developer is the first user of it.  It requires that we experience what using our software is really like.  Since we don’t like complicated interfaces, and since we can only imagine a limited amount of complication in our minds, we tend to naturally test against a simple interface and this makes the system easier to use for others too.

When we force ourselves to consider our tests first, it makes us expend more mental energy than we would if we were to just make the code.  This also challenges us to consider if what we are doing is really worth doing at all.  It has long been documented that 80% of our software is rarely if ever used.  Could it be that some of this is because software is easy to write but not easy to use? I haven’t done a scientific study to determine whether or not TDD would change the 80/20 rule, but my experiences as a test-driven developer have demonstrated to me that I have avoided unnecessary code when doing TDD because of the extra effort required to test it.

Another thing that TDD does is that it amplifies bad code designs.  That probably doesn’t sound good at first, but it really is.  It has been obvious as I have practiced TDD that when code is hard to test, it’s often because the design of the code itself is overly complicated. This is especially obvious when attempting to “back fill” tests by writing them last instead of first.  One of the common mistakes that new test-driven developers make is to assume that if a test takes a lot of mocking, it must mean that TDD is not very helpful.  Actually, when TDD is hard, it’s often pointing to a design that could use some work.  There are other reasons that TDD seems hard to new practitioners and I hope to share that in another post.  The point here is that when TDD creates ugly tests, it’s actually a benefit to us because it shows us the bad design earlier rather than later.  Good designs have clean and understandable interfaces.  Tests use interfaces and when those interfaces are not very intuitive, it tends to become obvious.

Another design benefit of TDD is the effect it tends to have on names.  How we name our classes, methods, functions and variables changes the readability of the code.  If code is easier to read, it’s much easier to maintain in the future.  That’s an important measure of software quality because software usually spends most of its life in maintenance mode.  The way that TDD improves names, is that it causes developers to think in terms of the problem domain.  When we test first, we focus on exposing a problem, so we tend to use wording that is a part of that problem’s domain.  When we write the code first, we often focus on our solutions.  We may use words like “loop” or “string”.  Those types of words don’t express the problem we are solving but the way that we are solving it.  I have found that when I use TDD, words from the problem domain find their way into public methods.  They may go deeper than that as well.  I don’t believe that TDD automatically generates a system with good names, but it appears to help us start off with better names than we would otherwise.