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

RE: [XP] UI Changes and communication to QA

Expand Messages
  • Desilets, Alain
    ... That happens to me surprisingly often. I m always surprised when XP people tell me they don t unit test the GUI code. TDD says, before you write or modify
    Message 1 of 77 , Apr 2, 2007
      Seyit Caglar Abbasoglu wrote:
      > I feel really bad
      > when something does not work only because I forgot to bind a
      > buttons event to a controller. And I really hate to test that
      > manually.

      That happens to me surprisingly often.

      I'm always surprised when XP people tell me they don't unit test the GUI code. TDD says, before you write or modify a single line of code, first write a failing test. Why do we think this does not apply to GUI code? Is it because GUI code is hard to test? If so, we just need to figure out a way to make it easier (and I and a few others have described some techniques for doing that). Or is it because we think GUI code is "trivial" and does not need to be tested? If it's the later, I would say that there is no such thing as "trivial" code. My GUI code breaks all the time and if I wasn't unit testing it, I would not find out until much later, at which point it's harder to zero in on the problem, and even worse, the system may have been deployed with a prominent GUI bug in it.

      Alain Désilets


      >
      > On 3/29/07, Steven Gordon <sgordonphd@...> wrote:
      > >
      > > Most teams do automated acceptance testing below the GUI (e.g.,
      > > Fitnesse)
      > > instead of throught the GUI (e.g., Watir, Selenium) because:
      > >
      > > - it makes the business rules more explicit,
      > > - testing through the GUI is brittle (changing the name or
      > location of
      > > a widget can break tests, even when the functionality still works
      > > perfectly), and
      > > - only manual testing can ascertain usability and aesthetic
      > qualities
      > > of the GUI.
      > >
      > > Steve
      > >
      > > On 3/29/07, Desilets, Alain
      > > <alain.desilets@...<alain.desilets%40nrc-cnrc.gc.ca>>
      > > wrote:
      > > >
      > > > > On 28 Mar 2007 08:38:23 -0700, Desilets, Alain
      > > > > <alain.desilets@...
      > <alain.desilets%40nrc-cnrc.gc.ca> <
      > > alain.desilets%40nrc-cnrc.gc.ca>> wrote:
      > > > > > Why not just unit test the UI
      > > > >
      > > > > Could you give a little explanation of what you mean by 'unit
      > > > > testing the UI'? Do you mean just the code that renders
      > the UI, or
      > > > > the whole application (front and back end)?
      > > >
      > > > Actually, unit testing was the wrong term to use. What I meant was
      > > writing
      > > > automated tests that exercise the whole application
      > through the GUI,
      > > > as would a QA person manually walking through a list of use cases.
      > > >
      > > > > I've never come across the latter being done before:)
      > > >
      > > > It's true that most XP teams do not test the GUI itself,
      > and stop at
      > > > testing the model behind the GUI. However, many QA teams use GUI
      > > scripting
      > > > tools to try and automate tests at the GUI leve, but as I
      > said in a
      > > previous
      > > > post, those scripts tend to break at the slightest change
      > in the GUI.
      > > >
      > > > But you can do it more robustly by writing say, jUnit tests that
      > > > have access to the code that implements the GUI, and which invoke
      > > > the widgets directly. For example, you can take a button
      > someButton
      > > > and do someButton.click(). Or, if you want to test even more
      > > > realistically, you can generate a click even that's tied to
      > > > someButton and post that event
      > > on
      > > > the event queue.
      > > >
      > > > I've done it a number of times and it catches bugs that are not
      > > > caught
      > > by
      > > > my unit testing of the model.
      > > >
      > > > ----
      > > > Alain Désilets, MASc
      > > > Agent de recherches/Research Officer Institut de technologie de
      > > > l'information du CNRC / NRC Institute for Information Technology
      > > >
      > > > alain.desilets@... <alain.desilets%40nrc-cnrc.gc.ca> <
      > > alain.desilets%40nrc-cnrc.gc.ca>
      > > > Tél/Tel (613) 990-2813
      > > > Facsimile/télécopieur: (613) 952-7151
      > > >
      > > > Conseil national de recherches Canada, M50, 1200 chemin Montréal,
      > > > Ottawa (Ontario) K1A 0R6 National Research Council
      > Canada, M50, 1200
      > > > Montreal Rd., Ottawa, ON K1A 0R6
      > > >
      > > > Gouvernement du Canada | Government of Canada
      > > >
      > > >
      > > >
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      > >
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
    • dnicolet99
      ... Isn t it unfortunate that it is necessary to say that at all? So many people forget that everything has a context. Dave
      Message 77 of 77 , Apr 4, 2007
        --- In extremeprogramming@yahoogroups.com, "Kelly Anderson"
        <kellycoinguy@...> wrote:
        >
        > TDD is valuable, but at some point it can just become zealotry or
        > religion. Diminishing returns have to be acknowledged to maintain
        > efficiency.
        >
        > -Kelly
        >
        Isn't it unfortunate that it is necessary to say that at all? So many
        people forget that everything has a context.

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