Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Behaviour Driven Development

Expand Messages
  • Ravi Mohan
    Hi all, I *still* don t get it. I have read Dave s paper and while I respect Dave immensely, this particular paper looked a little thin to me. Do correct me
    Message 1 of 106 , Oct 1, 2005
    • 0 Attachment
      Hi all,

      I *still* don't get it.

      I have read Dave's paper and while I respect Dave immensely, this
      particular paper looked a little "thin" to me.

      Do correct me If I am wrong, but is there such a big difference between

      shouldBeEmptyWhenFirstCreated
      shouldHaveASizeEqualToTheNumberOfItemsAdded
      shouldProvideAnIteratorOverAnyItemsAdded

      and

      testIsEmptyWhenFirstCreated
      testHasSizeEqualToTheNumberOfItemsAdded
      testProvideAnIteratorOverAnyItemsAdded

      Sure, in TDD , unit tests are used as specifications *and* as tests ,
      to ensure that existing functionality is not broken.Thus a unit test
      seems to function as a 'specification' as it is beng written, and a
      'test' afterwards.The change of naming convention seems to emphasize
      the "specification" aspect (tests are written to specify behaviour)
      while TestCase reflects the 'test' part (tests are written to verify
      that code works as expected).But a unit test has two purposes,
      specification AND verification.

      And all the "X < Context" examples I see still seem to work on the
      level of individual "units" or classes(see examples in Dave's paper).
      If one needs User Level tests , spanning multiple classes perhaps FIT
      ought to be used ?


      Here is a thought experiment. If the classes in JUnit were renamed
      from say TestCase to Context and say TestSuite to SpecificationSuite
      etc, do we have JBehave ?

      If so, isn't this just duplication of effort? If not what are the
      differences (at the code level) between an appropriately renamed Junit
      and JBehave? Yes, I'll look at the codebases but a short answer(or
      even better, examples that are significantly different using both
      frameworks) would be nice.

      Maybe people don't "get it" because they honestly can't see a
      (significant) difference. I thought anyone who *did* TDD (vs reading
      about it) would understand that unittests are specifications(also)?

      Regards,
      Ravi

      PS: I am not saying there is no difference between using say,Junit and
      JBehave. But it looks to me right now (and I am willing to be
      corrected) that the difference is fairly marginal. Please help me
      understand.


      --- In extremeprogramming@yahoogroups.com, Elizabeth Keogh
      <ekeogh@t...> wrote:
      > Hi Renzo,
      >
      > I'm working on JBehave in my spare time, so the whole BDD thing is very
      > big for me. I'd like to make a suggestion which I think will help
      you to
      > understand the paradigm shift better.
      >
      > For clarity, here's a summary of your methods:
      >
      > shouldAddToListImpl
      > shouldCallSizeAndHaveSizeOfOne
      > shouldFoundStarWars
      >
      > But these aren't descriptive of the behaviour of the class - they're
      named
      > after the acceptance criteria. To describe the behaviour of the class
      > better, I'd call them:
      >
      > shouldBeEmptyWhenFirstCreated
      > shouldHaveASizeEqualToTheNumberOfItemsAdded
      > shouldProvideAnIteratorOverAnyItemsAdded
      >
      > etc.
      >
      > You might add one item and expect to see a size of 1, but that's not
      the
      > behaviour you're designing; it's just one way that you can specify an
      > acceptance criteria for that behaviour. By naming the methods after the
      > behaviour, not the acceptance criteria, it's easier to see how the
      class
      > should perform and what its responsibilities are. I don't think it
      really
      > matters whether you use mocks, stubs or the real code here, nor do I
      think
      > it matters whether you add one, two or three items, as long as you can
      > verify, when you're done, that the class behaves as expected.
      >
      > Does this help describe the shift in thinking of BDD?
      >
      > Thank you for posting this, BTW. I've been telling everyone that you
      can
      > try out BDD by using "should" instead of "test", and the rest will
      > automatically follow; now I can see that it isn't true at all. I guess
      > I've always thought in terms of BDD, which is why I'm so passionate
      about
      > it, but it makes it very hard for me to understand why people "don't
      get
      > it" (or indeed, what it is that they "don't get").
      >
      > Your example has illuminated my problem and given me new insight. I
      hope
      > I've helped with yours.
      >
      > Regards,
      > Liz.
      >
      > --
      > Elizabeth Keogh
      > ekeogh@t...
      > http://www.livejournal.com/users/sirenian
      >
      >
      > extremeprogramming@yahoogroups.com wrote on 30/09/2005 11:16:48:
      >
      > > Well, I've read the paper. Thank you for pointing out the focus shift
      > > from "verification" to "specification". Anyway what I'm seeing here
      > > is a shift in the way to write state tests instead of a paradigm
      shift.
      > >
      > > Maybe I'm wrong but when I talk about testing behaviour, I'm thinking
      > > at something closer to mock driven developing, where the "Context" is
      > > an object instance along with its relationships to other instances
      > > and the way this network reacts to external stimuli. (for an in-depth
      > > look here http://www.jmock.org/oopsla2004.pdf for example).
      > >
      > > Now, why not to use the shift in writing test cases that Dave is
      > > describing to do mock behavioural testing? What I'm saying is that
      > > for example:
      > >
      > > class OneMovieList < Spec::Context
      > > def setup
      > > @list = MovieList.new
      > > star_wars = Movie.new "Star Wars"
      > > @... star_wars
      > > end
      > > def should_have_size_of_1
      > > @..._equal 1
      > > end
      > > def should_include_star_wars
      > > @..._include "Star Wars"
      > > end
      > > end
      > >
      > > is roughly equivalent in Java/Junit (sorry I don't know Ruby :) to:
      > >
      > > class OneMovieList extends Context {
      > > MovieList _movieList;
      > > void setUp() {
      > > _movieList=new MovieList();
      > > _movieList.add("Star Wars");
      > > }
      > > public void shouldHaveSizeOfOne() {
      > > shouldEqual(1, _movieList.size());
      > > }
      > > public void shouldIncludeStarWars() {
      > > shouldInclude("Star Wars", _movieList.iterator());
      > > }
      > > }
      > >
      > > that seems to me plain old state testing written with a different
      > > (and clearer) syntax. Now, what about this:
      > >
      > > class OneMovieList extends Context {
      > > MovieList _movieList;
      > > ArrayList _movieListMockImpl;
      > > void setUpState() {
      > > _movieList=new MovieList();
      > > _movieListMockImpl=mock(MovieListImpl.class);
      > > _movieListMockImpl.forwardTo(new ArrayList());
      > > _movieList.setListImpl(_movieListMockImpl);
      > > _movieList.add("Star Wars");
      > > _movieList.size();
      > > _movieList.contains("Star Wars");
      > > }
      > > public void shouldAddToListImpl() {
      > > shouldReceiveMessage("add", _movieListMockImpl).once();
      > > }
      > > public void shouldCallSizeAndHaveSizeOfOne() {
      > > shouldReceiveMessage("size", _movieListMockImpl).andReturn(1);
      > > }
      > > public void shouldFoundStarWars() {
      > > shouldReceiveMessage("contains", _movieListMockImpl)
      > > .with("Star Wars").andReturn(true);
      > > }
      > >
      > > In my opinion, the last OneMovieList class does behavioural testing
      > > as well as state tesing (and you can choose how deep to go with any
      > > of them). Just some thoughs.
      > >
      > > Bye
      > > Renzo
      >
      >
      >
      > [Non-text portions of this message have been removed]
    • Jeff Grigg
      ... It s those inductive loops they put in the rectangular cuts just before (and often crossing) the stop lines. I figure they must use those to read your
      Message 106 of 106 , Oct 14, 2005
      • 0 Attachment
        --- Ron Jeffries <ronjeffries@X...> wrote:
        > I was thinking "smart light". We have that story in our
        > list here in Michigan. The green arrow only goes on if
        > there are people wanting to turn. (I don't know how the
        > light knows what people want but I guess it's just
        > really intuitive. ;->)

        It's those inductive loops they put in the rectangular cuts just
        before (and often crossing) the stop lines. I figure they must use
        those to read your mind -- with some kind of magnetic field. ;->


        http://www.stjohns.ca/cityservices/traffic/howsignalswork.jsp

        http://auto.howstuffworks.com/question234.htm

        http://www.tfhrc.gov/pubrds/septoct98/loop.htm
      Your message has been successfully submitted and would be delivered to recipients shortly.