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

RE: [agile-usability] Re: Software transformations - extending ar chitectures

Expand Messages
  • Desilets, Alain
    ... The problem is that it depends on what you are testing. If you are testing pixels or mouse click locations, then GUI refactorings may cause problems: the
    Message 1 of 2 , Oct 26, 2004
      >
      > I haven't really thought about gui refactoring before, but on first
      > thought I came up with two ways of attacking the problem. First we can
      > look at our non-ui refactorings and see if we can come up with a
      > parallel gui version. For instance we know what MoveMethod looks like,
      > but what does MoveScreen look like? Second we can look at what we can
      > test on our gui and how we test it. If you can test something then you
      > can refactor it because you will have a test to prove your refactoring
      > didn't change functionality.

      The problem is that it depends on what you are testing. If you are testing
      pixels or mouse click locations, then GUI refactorings may cause problems:
      the difference in appearance between a pop-up menu and a set of radio
      buttons is substantial, but their functionality is essentially the same.
      GUI refactoring (at least as I am thinking of
      it) is changing the _GUI_design_ without changing the underlying
      functionality just like code refactoring changes the _code_design_ without
      changing behavior.

      -- Alain:
      Whenever I test GUIs, I use a HumbleDialogBox kind of approach:

      http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

      This is a simple approach where each dialog is represented by a Model and a
      View. The Model is an object that is pretty much presentation neutral. You
      write your tests by invoking presentation neutral methods of the Model (ex:
      doSelectDay(n) instead of dayList.doClickNthEntry(n)).

      One nice thing about that is that your tests remain valid even if the
      pressentation layer changes significantly. For example, if you started out
      with the list of days being implemented as a drop down list and then you
      decide that it's more usable to have it be a text box, then all you have to
      do is change the implementation of doSelectDay(n) so that it types the month
      "n" in the text field.

      Of course, this kind of testing doesn't tell you anything about what part of
      the presentation should be refactored and in what direction. But once you
      have decided how to change the presentation, that kind of tests allow you to
      do it with confidence.
      ----
    • Michael Mahemoff
      ... A recurring theme in agile GUI development is to push as much functionality away from the GUI objects. Here is an interesting framework I came across
      Message 2 of 2 , Nov 3, 2004
        >
        > The problem is that it depends on what you are testing. If you are testing
        > pixels or mouse click locations, then GUI refactorings may cause problems:
        > the difference in appearance between a pop-up menu and a set of radio
        > buttons is substantial, but their functionality is essentially the same.
        > GUI refactoring (at least as I am thinking of
        > it) is changing the _GUI_design_ without changing the underlying
        > functionality just like code refactoring changes the _code_design_ without
        > changing behavior.
        >
        > -- Alain:
        > Whenever I test GUIs, I use a HumbleDialogBox kind of approach:
        >
        > http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf
        >
        > This is a simple approach where each dialog is represented by a Model and a
        > View. The Model is an object that is pretty much presentation neutral. You
        > write your tests by invoking presentation neutral methods of the Model (ex:
        > doSelectDay(n) instead of dayList.doClickNthEntry(n)).

        A recurring theme in agile GUI development is to push as much
        functionality away from the GUI objects. Here is an interesting
        framework I came across recently, based on Webwork, which separates
        workflow from Swing components and therefore supports unit testing as
        much as possible on the GUI side.

        Pendulum: http://sourceforge.net/projects/pendulum/
      Your message has been successfully submitted and would be delivered to recipients shortly.