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

RE: [XP] UI Changes and communication to QA

Expand Messages
  • Charlie Poole
    Hi Alain, ... Hopefully you didn t mean to generalize about what XP people say. After all, here you are and you test your GUI - as do many of us. However,
    Message 1 of 77 , Apr 2, 2007
      Hi Alain,

      > 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.

      Hopefully you didn't mean to generalize about what "XP" people say.
      After all, here you are and you test your GUI - as do many of us.

      However, not testing a /particular/ aspect of the code is different
      from not testing the GUI. For example, I almost never unit-test the
      position of controls on a form and usually only test the presence
      of controls indirectly - by attempting to find them for some other
      test.

      Addressing your two possible reasons why people don't test:

      Because it's hard to test... That's my favorite gui topic! If the
      person who gives that as a reason means that GUIs in general are
      hard to test, then they are wrong. They're no harder to test than
      many of the other hard things we do, but they do require specialized
      knowledge, some of it platform specific, which means that talking to
      a Java guy, for example, won't help you on specifics if your gui is
      written in C++.

      OTOH, I find that the "hard to test" argument usually applies to
      the speakers particular GUI design. In which case the answer is
      "Stop doing that!" Testing GUIs is the best way I know to drive them
      to become testable, which generally means "well-designed with proper
      separation of concerns, minimal coupling, etc."

      Because its trivial and does not need to be tested... I think that
      reason is a problem with the discussion medium. People tend to come up
      with simplistic examples, which at least some folks find it unnecessary
      to test. But testing that a custom control generates the proper events
      or responds to domain-level events in the correct way is definitely not
      trivial and is subject to lots of errors.

      I always find it amusing that the "hard to test" and "trivial" arguments
      often come up in the same discussion!

      There's a third reason that I've heard, which may make some degree of sense.
      It's that most guis are not coded: they are dragged and dropped. Folks say
      that there is no need to test the generated code. Of course, it's possible
      that one has dragged and dropped the wrong stuff, but if other tests are
      present, then this failure will be rapidly uncovered. I can give an example
      of this: I have a custom control which is tested by passing it an event
      source
      and seeing how it responds to a series of artificial events. There is no
      test
      to see that each event is actually bound to a method, but each event is
      tested in terms of the behavior that is expected, so failing to bind to
      an event would obviously generate an error.

      IMO unit-testing applies to guis just as it does to anything else - even
      if some of us have not yet learned how to test certain specifics. But
      broader, behavior-based tests are pay off more for the effort than tests
      that zero in on small things like whether we are binding properly.

      Charlie

      > 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
      > >
      > >
      > >
      > >
      >
      >
      > 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.