Download the Podcast
How unit tests inform us about our design
As proponents of Test-Driven Development, we constantly seek to identify and point out the various ways that the effort one puts into writing tests will be of value to the development team. As with most highly-powerful techniques, TDD tends to deliver multiple values across the entire development effort.
One example is this:![]()
Test Reflexology, Part 1 (first post)
↧
↧
Test Reflexology, Part 1 (second post)
Download the Podcast
...continued from previous post...
Overly Protective Test
Sometimes when examining a test we find it to be much larger in size than the production class. Oftentimes we can just split the test into multiple tests – but not in this case – remember our initial assumption is that the tests are as good as they can get. What could be the cause then? It could be because the test![]()
↧
Redefining Test-Driven Development, Pt. 1
Download the Podcast
How you do something new is often influenced to a great extent by what you think you are doing -- its precise nature, the steps and work-flows, and how it relates to other things that you already do and understand. The term “Test-Driven Development”, while well-established in our industry, is perhaps an unfortunate choice of words to describe what we are doing, and![]()
↧
Redefining Test-Driven Development, Pt. 2
Download the Podcast
In part 1 we said “How you do something new is often influenced to a great extent by what you think you are doing.” Let’s add that, similarly, changing the way you do something you are already doing can come from a new understanding of its nature.
Something development teams already do (or, in our opinion, really should be doing) is to write a specification of the![]()
↧
Lies, Damned Lies, and Code Coverage
Download the Podcast
As unit testing has gained a strong foothold in many development organizations, many teams are now laboring under a code coverage requirement. 75% - 80% of the code, typically, must be covered by unit tests. Most popular Integrated Development Environments (IDE’s) include tools for measuring this percentage, often as part of their testing framework.
Let’s ask a![]()
↧
↧
Testing Best Practices: Test Categories, Part 1
Download the Podcast
Successfully adopting and practicing TDD in a sustainable way involves many distinctions, best-practices, caveats, and so forth. One way to make such information accessible is to put in into a categorized context. The Design Patterns, for instance, are often categorized into behavioral, structural, and creational.[1] Here we will do a similar thing with the![]()
↧
Testing Best Practices: Test Categories, Part 2
download the podcast
Continued from Test Categories, Part 1
5. Behavior with related boundaries (“and”)
Sometimes a behavior varies based on more than one factor. For example, let’s say that in order for the system to allow someone to be hired (returning a true from the canHire() method, perhaps), the individual in question must both be at least 18 years old and must be a US citizen.![]()
↧
Testing Best Practices: Test Categories, Part 3
download the podcast
Continued from Test Categories, Part 2
Constant Specification
We often find values that are significant to a given problem domain, but are otherwise arbitrary. For example, the sales tax rate in a state might be .08 (8 percent), but this is just the rate as currently defined by that state’s government.
Similarly, we sometimes have enumerations that are also![]()
↧
ATDD and TDD
Download the Podcast Part 1
Download the Podcast Part 2
A question that we are often asked is: “What is the difference between Acceptance Test Driven Development (ATDD) and Test Driven Development (TDD)?” These two activities are related by name but otherwise seem to have little to do with each other.
ATDD is a whole-team practice where the team members discuss a requirement and come to an![]()
↧
↧
The Importance of Test Failure
The typical process of Test-Driven Development goes something like this:
Write a test that expresses one required behavior of the system.
Create just enough production code (a “stub”) to allow the test to compile, and fail.
Run the test and watch it fail (red).
Modify the production code just enough to allow the test to pass.
Run the test and watch it pass (green).
Refactor the production code![]()
↧
Notice: Test Categories finally finished
This was an edit to an existing blog posting, so you might have missed it... but, we finally did finish part 3 of test categories. Whew!
It's here: http://www.sustainabletdd.com/2012/02/testing-best-practices-test-categories.html![]()
↧
Mock Objects, Part 1
Download the podcast.
Narrow Specifications
When writing tests as specifications, we strive to create a very narrow focus in each individual test. We want each test to make a single, unique distinction about the system. This creates a clear specification when we later read the test, and also creates the maximum value when the test fails.
If a test makes a single distinction, then when it![]()
↧
Mock Objects, Part 2
Download the podcast.
Techniques
There are many ways to create a mock object by hand. You will likely come up with your own techniques, which may make use of language elements and idioms made possible by the particular languages and frameworks you work with. It is important to know more than one technique because under various circumstances during the development process we are able and![]()
↧
↧
Mock Objects, Part 3
Dependency Injection
Imagine that the example use previously was implemented differently:
public class BoundaryAlarm {
private GPS myGPS;
private DashLight myDashLight;
public BoundaryAlarm(){
myGPS = new GPSImpl();
myDashLight = new DashLightImpl();
}
public void CheckFieldLocation(){
// Implementation unchanged
}
}
The![]()
↧
Upcoming Blog: Testing the Chain of Responsibility
Our next blog is going to be the first in a series of blogs that focus on testing the design patterns, and what we can learn about TDD and design from these investigations. However, the discussion does require that you understand the pattern before we begin.
So, if you are not completely comfortable with the Chain of Responsibility, it would be a very good idea for you to read up on the pattern![]()
↧
Testing the Chain of Responsibility, Part 1
The
Chain of Responsibility pattern (hereafter CoR) is one of the original
“Gang of Four” patterns. We’re assuming you know this pattern already,
but if not you might want to read about it first at the Net Objectives Pattern Repository:
Here’s the UML at it appears in the Gang of Four book [1]:
In testing this pattern, we have a number of behaviors to specify.
Individual Handler Behavior![]()
↧
Mock Object Podcast, Pt. 1
Just a heads up, we finally got the podcasts associated with our blogs on mocking done.
Mock Object Podcast, Pt. 1![]()
↧
↧
Mock Object Podcast, Pt. 2
...and here is the second one. We have to post them separately like this in order for feedburner to pick them up and propagate them to iTunes...
Mock Object Podcast, Pt. 2![]()
↧
ATDD and TDD Podcast, Part 2
It turns out that you can only place 1 podcast per blog and have iTunes pick it up. So, this blog posting is just to get part two of the ATDD and TDD podcast to our iTunes subscribers. If you are a non-iTunes visitor, this will not effect you.
The Podcast, Part 2![]()
↧
A Learning Process: Re-doing CoR part 1
We're writing this blog for several reasons:
To work out the intellectual material for the book we're writing
To provide value to our community as quickly as possible
To get feedback from our readers as soon as possible (validation-centric)
However, we're also finding that the process of creating each blog and each podcast is, in and of itself, a learning process. In recording the podcast for![]()
↧
More Pages to Explore .....
