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 while we are creating the blog posting.
Here is a link to our pattern repository page on the CoR. Please take a few minutes to read it through and post any questions you have here in our comments section.
The Chain of Responsibility
Hi, The question I always had was this: how does TDD lead to patterns (in particular the non-trivial ones)? I mean, I know that both TDD and patterns are about the same qualities, but where is the point where "sketching" the solution using test-first leads you to the conclusion "oh yes, this is going to be a chain of responsibility". Is it the result of what the test says or is it more of a result of analysing about different solutions to problems using the design knowledge gained elsewhere?
ReplyDeleteI've been on a training or read a blog post (don't remember which was it) where you presented a stream of thought that led you to evolve two-level inheritance into the bridge pattern using design qualities - it would be nice to see how something like this looks in case of chain of responsibility using TDD.
To quickly answer your question (and we will go into it at length in the blog), the CoR pattern is specified by a series of TDD tests [TS] (which are specifications, of course). You could start with this series of tests [TS] (becuase you know in advance that the problem is a Chain of Responsibility) or can start with one test, and add more until you have the complete suite [TS] and observe the CoR in your code (as you've asked us to demonstrate).
ReplyDeleteEither way you should arrive at the same test suite and the same design. It's a great idea to demonstrate both. Thanks.
Thanks, Amir!
ReplyDeleteAnother idea that came to my mind while reading your answer is this: there is a probability that you'll get, let's say, two distinct chains of responsibility in your code. While the goal of patterns is not primarily implementation reuse, I expect jumping into having similar suites for both chains. So, following your thought that such a case suggests redundancy, maybe it would be a great way to show which parts of the pattern can be made common (if any) and which not...
Just a quick thought.