Download the podcast
Testing the Chain of Responsibility
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.
The
basic idea is this: you have a series of rules (or algorithms) that are
conceptually the![]()
Testing the Chain of Responsibility, Part 1 (redux)
↧
↧
Testing the Chain of Responsibility, Part 2
Download the podcast
Chain Composition Behaviors
We always design services for multiple clients. Even if a service (like the Processor
service in our example) has only a single client today, we want to
allow for multiple clients in the future. In fact, we want to promote
this; any effort expended to create a service will return increasing
value when multiple clients end up using it.
So,![]()
↧
Testing Through API's
Download the Podcast
We recently got a question from Tomas Vykruta, a colleague of ours, and we felt it turned out to be such a good, fruitful question that we wanted to pass it, and our answers, along in this blog.
Here is Tomas' question:
Do you prefer to have unit tests written against the public API, or to test individual functions inside the API? I've seen both approaches at my company,![]()
↧
Hiatus
We just wanted to make clear to our readers that this blog, and the book we are working on through it, are not dead. Amir and I have just been in very high demand for training since the holidays, but we will be back! Stay tuned.....
-Scott-![]()
↧
TDD Mark 3 Introduced
First of all, sorry for the long absence. Our training schedule has been wall-to-wall, and when one of us had a brief gap the other has always been busy.
It has given us time to think, however. Long airplane rides and such. :)
We're been playing around with an idea we're calling (for the moment) TDD Mark 3 (the notion that TDD is not about testing but rather about specification being TDD![]()
↧
↧
TDD and Asychronous Behavior: Part 1
<!--[if gte mso 9]><![endif]-->
In TDD we write tests as specifications where each of them is focused on a single behavior of the system. A “good” test in TDD makes a single, unique
distinction about the system.
But this means when the TDD process is complete our spec also serves as a suite of tests against
regression. This is a hugely valuable side-effect of TDD. We don’t![]()
↧
TDD and Asychronous Behavior: Part 2
<!--[if !mso]>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
<![endif]--><!--[if gte mso 9]><![endif]--><!--[if gte mso 9]>
Normal
0
false
false
false
false
EN-US
X-NONE
X-NONE![]()
↧
Welcome Max Guernsey
Max has joined Net Objectives, as some of you may know, as a trainer, coach, and mentor. We've been friends with Max for a long while, and he has been a contributor to this blog and to the progress of our thinking in general.
So, we're adding him to the official authorship here and when (if ever :)) we get this thing written, he will be co-author with Amir and I.
I know this has been terribly![]()
↧
TDD and Defects
We've said all along that TDD is not really about "testing" but rather about creating an executable form of specification that drives development forward. This is true, and important, but it does not mean that TDD does not have a relationship to testing. One interesting issue where there is significant synergy is in our relationship to defects.
Two important issues we'll focus on are: when/how![]()
↧
↧
TDD and Its (at least) 5 Benefits
Many developers have concerns about adopting test-driven development, specifically regarding:
It's more work. I'm already over-burdened and now you're giving me a new job to do.
I'm not a tester. We have testers for testing, and they have more expertise than I do. It will take me a long time to learn how to write tests as well as they do.
If I write the code, and then test it, the test-pass![]()
↧
Structure of Tests-As-Specifications
(Please note: this post is being revised... expect improvements to be made)
A big part of our thesis is that TDD is not a testing activity, but rather a specifying activity that generates tests as a very useful side effect. For TDD to be a sustainable process, it is important to understand the various implications of this distinction.
Here, we will discuss the way our tests are structured![]()
↧
Specifying The Negative in TDD
One of the issues that frequently comes up is "how do I write a test about a behavior that the system is specified not to have?" It's an interesting question given the nature of unit tests. Let's examine it.
The Decision Tree of Negatives
When it comes to behaviors that the system should not have, there are different ways that this can be specified and ensured for the future:
Inherently![]()
↧
TDD and the "6 Do's and 8 Skills" of Software Development: Pt. 1
This post is not about TDD per se, but rather a context in which TDD can demonstrate its place in and contribution to the value stream. This context has to do with the 6 things that we must accomplish (do) and the 8 skills that the team must have in order to accomplish them. We'll describe each "do", noting where and if TDD has an impact, and then do the same thing with the skills.
6 Dos:
Do![]()
↧
↧
TDD and Design: Frameworks
Increasingly, in modern software development, we create software using components that are provided as part of a language, framework, or other element of an overall development ecosystem. In test-driven development this can potentially cause difficulties because our code becomes dependent on components that we did not create, that may not be amenable to our testing approaches, and that the test![]()
↧
Magic Buttons and Code Coverage
This will be a quickie. But sometimes good things come in small packages.
This idea came to us from Amir's good friend Eran Pe'er, when he was visiting Net Objectives from his home in Israel.
I'd like you to imagine something, then I'm going to ask you a question. Once I ask the question you'll see a horizontal line of dashes. Stop reading at that point and really try to answer the question.![]()
↧
TDD: Testing Behavior in Abstract Classes
<!--[if !mso]>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
<![endif]--><!--[if gte mso 9]><![endif]--><!--[if gte mso 9]>
Normal
0
false
false
false
false
EN-US
X-NONE
X-NONE![]()
↧
Test-Driven Development in the Larger Context: TDD & ATDD (Introduction)
Introduction
A question that often arises in our consulting and training practices concerns the relationship between Test-Driven Development (TDD) and Acceptance-Test-Driven Development (ATDD). Which is “really” TDD, and which should an organization focus on in terms of which comes first, and which should achieve the most attention and resources?
It’s not uncommon for someone to refer to TDD as![]()
↧
↧
Test-Driven Development in the Larger Context: Pt 1. Audience
<!--[if !mso]>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
<![endif]--><!--[if gte mso 9]><![endif]--><!--[if gte mso 9]>
Normal
0
false
false
false
false
EN-US
X-NONE
X-NONE![]()
↧
Test-Driven Development in the Larger Context: Pt 2. Cadence
<!--[if gte mso 9]><![endif]--><!--[if gte mso 9]>
Normal
0
false
false
false
EN-US
X-NONE
X-NONE<![endif]--><!--[if gte mso 9]>![]()
↧
Test-Driven Development in the Larger Context: Pt 3. Automation
Both ATDD and UTDD are automatable. The difference has to do with the role of such automation, how critical and valuable it is, and when the organization should put resources into creating it.
AUTOMATION
ATDD
ATDD’s value comes primarily from the deep collaboration it engenders, and the shared understanding that comes from this effort. The health of the organization in general, and![]()
↧
More Pages to Explore .....
