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

Re: Extending TDD to ATDD

Expand Messages
  • Matthew
    ... I suspect it really comes down to where your bugs come from. For example, at Socialtext, we have a watch page feature. You click a star that says
    Message 1 of 31 , Mar 1, 2011
    View Source
    • 0 Attachment
      --- In agile-testing@yahoogroups.com, John Goodsen <jgoodsen@...> wrote:
      >
      >with over 50% of your code in the GUI layers, the argument to not test thru
      >the GUI becomes a cop out for writing and maintaining good acceptance
      >tests... google "declarative vs imperative cucumber" for more on that...
      >
      >yes, I know I'm on the controversial side of that one...
      >

      I suspect it really comes down to where your bugs come from. For example, at Socialtext, we have a 'watch page' feature. You click a star that says "watch page", the star lights up, then you clicked the "watched pages" link, the page now appears in the link. Go back, unwatch, watched pages, page does *not* appear.

      That's not the kind of thing I want to test through the business logic layer.

      Our /whole app/ is like that.

      We do have javascript unit tests, but I find they are more helpful to the developers than to the testers -- a failure doesn't really indicate something is broken, a pass doesn't indicate it isn't ... they function more like change detectors.

      We have also had a fair amount of success with GUI automation with Selenium, but a lot of that is due to the nature of our product and development process. In general, I recommend exploratory testing the GUI and a few small, light, quick, build verification GUI-driving tests.

      Meanwhile, on the Software-Testing Discussion list, Elisabeth Hendrickson is making a big deal about how ATDD is /Acceptance/ Test Driven Development - not "Automated Testing During Development", and Ken Pugh is pointing out that you can do ATDD without automation:

      http://groups.yahoo.com/group/software-testing/

      Might be something to consider here, as, well, as I am /certainly/ not picking up that vibe here.

      regards,



      --
      Matthew Heusser,
      Personal Blog: http://xndev.blogspot.com/
      Test Community Blog: http://softwaretestpro.com/blog/
      Twitter: mheusser
    • Mark Levison
      On Mon, Mar 7, 2011 at 9:38 AM, Charles Bradley - Scrum Coach CSM PSM I
      Message 31 of 31 , Mar 7, 2011
      View Source
      • 0 Attachment
        On Mon, Mar 7, 2011 at 9:38 AM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
         

        Mark,


        > I assume in this last part Charles is just saying what most of us say: test underneath the GUI as much as possible.
        Yes, agreed, except I did add that part about "testers and developers" coming together in a "natural meeting place" we sometimes call "service layer testing".  I think this "natural meeting place" is a good way for teams to become more efficient and more cross functional(a la Scrum), which adds a whole new set of cost savings.  The "natural meeting place" was speaking more to team dynamics than test efficiency.

        I guess a better statement of my point would be that I was trying to bridge the gap with Matt. Too most clients (who's app isn't mostly JavaScript), I recommend

        - 20-25% of their acceptance tests through the GUI
        - the remainder underneath the GUI

        As an example my current client is testing their advanced search functionality. Its largely business logic and so I say test it through the business layer for the most part. However the GUI should still be tested to ensure that: things that can go wrong there are tested and that its correctly wired. This tradeoff gives them a set of tests that run quickly (minutes) vs. the GUI only tests of yore (hours).


        > In these cases the tests often wind up describing a form of public API.
        I think I agree with everything here except "public".  To me, "public" API implies that you are planning to let other teams use your API directly.  IMO, much more thought has to be given to an API before one makes it "public."

        Hence my use of the word "form". It maybe a public API but you're giving people access to it. Example said search functions are written in C#, the application now exposes them as Objects/Methods. Other applications in the client's stack could make use of this API, however you couldn't because you will never have access to the process to speak to the API.

        Cheers
        Mark Levison

        MarkMark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
        Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
        Recent Entries:
        Story Slicing How Small is Small Enough, Why use an Agile Coach


      Your message has been successfully submitted and would be delivered to recipients shortly.