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

RE: [XP] Re: User interface

Expand Messages
  • Andrei GHEORGHE
    long message ... Hi! I ve done automated acceptance tests for a GUI app. The GUI is written in C++/MFC. If I ve made it with such an old
    Message 1 of 1 , Feb 6, 2003
      <Warning> long message </Warning>

      > ----- Original Message -----
      > From: "Ali Tüzünkan" <atuzunkan@...>
      > To: <extremeprogramming@yahoogroups.com>
      > Sent: Wednesday, February 05, 2003 4:29 AM
      > Subject: [XP] User interface
      >
      >
      > Hi all,
      > Should User Interface tests be automated? If so, which
      > software can I
      > use? I believe it is so diffucult to make it automated.
      > Ali

      Hi!

      I've done automated acceptance tests for a GUI app. The GUI is written in
      C++/MFC. If I've made it with such an old and awkward library, you can make
      it too :)

      We have the tests written in VBScript. Each script contains commands, that
      simulate the commands given by a human user (selecting something from a
      menu, pressing a key, pushing a button, etc.).

      You don't need VBScript. You can take a look at Adventures in C# on
      XProgramming.com, for an example of a simple scripting mechanism, that does
      the job.

      For an easy access to the classes of the application, our testing engine
      runs in the same process with the application to be tested. It is not a
      separate application, it is a module (dll) of the same app.

      Just a few hints/problems that you might encounter:

      **Modal dialog boxes**

      As you probably know, a modal dialog box is a dialog box that does not allow
      you to work with the application until you don't close it. Like
      "Tools/Options" dialog, in MSWord.
      If you launch a command from the testing engine, that has an effect of
      showing a modal dialog box, your thread is blocked, until you close the
      dialog box. So human interaction is needed in order to close the dialog. To
      solve this:

      For modal dialog boxes used for giving messages to the user, like ("File not
      saved, save it now? Yes/No/Cancel") you can use something like:

      class IMessageBoxes
      {
      enum Result
      {
      Yes, No, Cancel, OK
      }

      vitual Result messageBox(string message) = 0;
      }

      class MessageBoxes : public IMessageBoxes
      {
      vitual Result messageBox(string message)
      {
      // pops a dialog box, using GUI API
      }
      }

      class StubMessageBoxes : public IMessageBoxes
      {
      void expectedMessageBox(string messageToReceive, Result result)
      {
      // add (messageToReceive,result) to a list
      }
      vitual Result messageBox(string message)
      {
      // - take the first item in the list
      // ASSERT message is the same as in the item
      // return the result from the item
      }
      }

      The application has a global object of type IMessageBoxes, that is set to
      MessageBoxes when the application runs normally, and to StubMessageBoxes,
      when you run the testing engine.

      In the script you write something like:

      ===
      app.expectedMsgBox("File not saved", "Cancel")
      app.close()
      ==

      When app.expectedMsgBox is executed, it calls
      StubMessageBoxes::expectedMessageBox.
      When app.close is executed, it calls the close command on your application
      (or sends a message), that in turn will call StubMessageBoxes::messageBox.

      ----

      For other modal dialog boxes, well, it depends. We don't have many of them
      in the application, and we just Unit Test them.

      **Asserting visual results**

      Another potential problem is asserting visual results. For example, you
      execute some command, and then you want to assert that some specific objects
      are selected, or the color of an object has changed to blue, or...

      One solution, suggested by Keith Ray on this list, is to draw the output
      into a bitmap, and then compare the bitmap with a good one, found on disk.
      (I haven't used this solution)

      Another solution is to have a model of what you have to render. For example
      if your app paints triangles, circles, etc, the model will be a list of
      objects that represent triangles, circles, etc. Each object has the
      coordinates where to draw itself, the color, etc.
      The rendering engine is a simple class that iterates through your list and
      asks the objects to draw themselves.
      After each operation you make, you can do the assert, by taking the results
      directly from your model(from the list, in the above case), not from the
      screen.


      I hope you've understood something from my pseudo explanations :) and from
      my mixed C++/Java code examples.

      If you can tell us more about your app, about what you cannot test, maybe we
      can give you more concrete advices.
      --Andrei.
    Your message has been successfully submitted and would be delivered to recipients shortly.