The Zen of BDD
Olof Bjarnason
how much easier to use my classes became.
(1) But I always had the feeling TDD was "designing the smale scale" -
object level interfaces specifically. The "architecture" or "class
hierarchies" was still BUFD:ed in my head or, sometimes, on paper. But
at the implementation level, it was bottom-up-design.
(2) Another issue I had with TDD was that sometimes I built too much
functionality into my classes, and in the worst case a whole class was
deprecated because higher-level functionality didn't really need them
after all!
(3) Of course I've been through the "it is hard to test GUIs,
databases, files, random algorithms"-era of my TDD-quest too. I was
fortunate enough to begin my TDD-journey with an all-algorithmic
problem -- the problem of packing small rectangles in a big rectangle
(also known as nesting). A no-external-dependencies project! I would
call it beginners luck!
So reading about BDD I got quite interested, since it seemed to me
that it addressed these issues: It is top-down-design (issue 1 and 2
solved!). Issue (3) is something I've been solving with inversion-of-
control/dependency-injection in my TDD:ing and it just got even more
obvious with BDDs mocking-centric method, I guess.
How did you guys go about learning BDD?
Brian Donahue
Have you seen Scott Bellware's article in the recent issue CoDe magazine? That would be a great place to start. Looking at RSpec and BDD examples and conversations in the Ruby community, where BDD has a little more traction, is also helpful. BDD (especially as it pertains to .NET and C#) is still in its nascency, and most of the people talking about it are still learning, experimenting, and figuring out what seems to work, what old assumptions need to change, etc. I try to learn by trying the ideas for myself in my work, and continuing to read about and discuss it with others to see where there explorations are taking them.
Olof Bjarnason
Link? I googled some minutes and did not find any obvious Bellware
article on this exact subject (the "getting started with BDD"-subject
i mean).
2008/5/20 Brian Donahue <br...@pigeonmoon.com>:
Brian Donahue
http://www.code-magazine.com/Article.aspx?quickid=0805061
Unfortunately it is only available in full to subscribers. You have to either find a copy to buy, or subscribe - but it's a good article, worth a little effort to see if you can track down a copy.
Pat Maddox
<olof.bj...@gmail.com> wrote:
>
> When I started using TDD I really liked the confidence I felt - and
> how much easier to use my classes became.
>
> (1) But I always had the feeling TDD was "designing the smale scale" -
> object level interfaces specifically. The "architecture" or "class
> hierarchies" was still BUFD:ed in my head or, sometimes, on paper. But
> at the implementation level, it was bottom-up-design.
TDD doesn't mean you don't think about design at all. Thinking
through a design in your head, or a few sketches on paper, is not
BUFD. It's just smart.
> (2) Another issue I had with TDD was that sometimes I built too much
> functionality into my classes, and in the worst case a whole class was
> deprecated because higher-level functionality didn't really need them
> after all!
I find an outside-in style of development to be very helpful with this
kind of problem. It forces you to think of your objects at a high
level, so your design is driven by real need, and then you apply your
design skills as you go on. When I use a pure bottom-up style, I
write more speculative code and go down the wrong path far more often
than I'd like. That's not to say that it's a problem inherent with
that style, but rather a problem that I've personally experienced, and
have more or less solved by using an outside-in approach.
> (3) Of course I've been through the "it is hard to test GUIs,
> databases, files, random algorithms"-era of my TDD-quest too. I was
> fortunate enough to begin my TDD-journey with an all-algorithmic
> problem -- the problem of packing small rectangles in a big rectangle
> (also known as nesting). A no-external-dependencies project! I would
> call it beginners luck!
Yep, dependencies are tough. The only real advice I can give is to
listen to your code and tests - whenever you feel pain, ask yourself
(and team members, and mailing lists) how you can remove it.
Pat
Olof Bjarnason
>
> On Tue, May 20, 2008 at 2:14 AM, Olof Bjarnason
> <olof.bj...@gmail.com> wrote:
>>
>> When I started using TDD I really liked the confidence I felt - and
>> how much easier to use my classes became.
>>
>> (1) But I always had the feeling TDD was "designing the smale scale" -
>> object level interfaces specifically. The "architecture" or "class
>> hierarchies" was still BUFD:ed in my head or, sometimes, on paper. But
>> at the implementation level, it was bottom-up-design.
>
> TDD doesn't mean you don't think about design at all. Thinking
> through a design in your head, or a few sketches on paper, is not
> BUFD. It's just smart.
>
But I'm trying to learn BDD, see the last paragraph of the top thread.
>
>> (2) Another issue I had with TDD was that sometimes I built too much
>> functionality into my classes, and in the worst case a whole class was
>> deprecated because higher-level functionality didn't really need them
>> after all!
>
> I find an outside-in style of development to be very helpful with this
> kind of problem. It forces you to think of your objects at a high
> level, so your design is driven by real need, and then you apply your
> design skills as you go on. When I use a pure bottom-up style, I
> write more speculative code and go down the wrong path far more often
> than I'd like. That's not to say that it's a problem inherent with
> that style, but rather a problem that I've personally experienced, and
> have more or less solved by using an outside-in approach.
>
Yup, and outside-in is what BDD is supposed to be about, I think. It's
still very fuzzy to me, that's why I joined this mailing list.
>
>> (3) Of course I've been through the "it is hard to test GUIs,
>> databases, files, random algorithms"-era of my TDD-quest too. I was
>> fortunate enough to begin my TDD-journey with an all-algorithmic
>> problem -- the problem of packing small rectangles in a big rectangle
>> (also known as nesting). A no-external-dependencies project! I would
>> call it beginners luck!
>
> Yep, dependencies are tough. The only real advice I can give is to
> listen to your code and tests - whenever you feel pain, ask yourself
> (and team members, and mailing lists) how you can remove it.
>
Yeah, pain is a great smell of bad code :)
> Pat
>
> >
>