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

Re: [XP] UI Changes and communication to QA

Expand Messages
  • Michael Foord
    ... We have a large suite of functional (acceptance) tests for our Windows Forms application (written in IronPython). It has taken a lot of work to get the
    Message 1 of 77 , Mar 31, 2007
    • 0 Attachment
      Seyit Caglar Abbasoglu wrote:
      >
      > There are many problems as you stated when testing through GUI, and
      > most of
      > them, as Mr. Poole stated, because of the low testability support of
      > GUIs we
      > use. I don't like to fire weird events for Windows Forms, but also 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. If
      > you create some golden rules, testing primary functionalities through
      > GUI is
      > not that bad (at least for Windows Forms).
      >







      We have a large suite of functional (acceptance) tests for our Windows
      Forms application (written in IronPython). It has taken a lot of work to
      get the test framework reliable and straightforward, but writing new
      tests is now (mainly) easy and effective.

      Definitely worth all the effort we put in - all our user stories are
      fully tested through functional tests.

      Michael Foord
      http://www.voidspace.org.uk/python/weblog/index.shtml

      >
      > On 3/29/07, Steven Gordon <sgordonphd@...
      > <mailto:sgordonphd%40gmail.com>> 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@...
      > <mailto:alain.desilets%40nrc-cnrc.gc.ca><alain.desilets%40nrc-cnrc.gc.ca>>
      > > wrote:
      > > >
      > > > > On 28 Mar 2007 08:38:23 -0700, Desilets, Alain
      > > > > <alain.desilets@...
      > <mailto:alain.desilets%40nrc-cnrc.gc.ca>
      > <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@...
      > <mailto:alain.desilets%40nrc-cnrc.gc.ca>
      > <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]
      >
      >
    • 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
      • 0 Attachment
        --- 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.