headers
Phlip | 15 Jun 2004 01:59
Picon
Favicon

Re: Automated Testing tools

Ravi wrote:

> 1. Any good resources/tools for automated testing
> tools for 
> SWT/Swing for User acceptance testing ? I have
> looked only at Abbot 
> and basic Robot framework.
> 2. Is it worth testing the GUI or just test the
> model ?

Acceptance tests are not GUI tests, and vice versa.
But testing a GUI is worthwhile, unless you want bugs
in the layer closest to your users.

Thibaud Bouquely wrote:

> But we have too some component for the GUI
> of ours applications (Grid, edit,
> group box, check box, etc. ...) for the
> grid, for exemple, we have may be
> 9000 lines of codes !!!

Why didn't you get a 3rd party grid?

("Because we didn't feel like it" is a valid
answer...)

> We develop this tool box with Delphi for seven
> years. and we want now
> developp "from crach" a new tool box on .NET
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 17 Jun 2004 01:08
Picon
Favicon

[TFUI] Unit Testing a Smalltalk GUI

From the XP newsgroup:

Phlip wrote:

> danp wrote:
>
> > Ive bitten the bullet and unit tested a few simple
> > dialog boxes. Much
> > easier
> > than I first though. However, encountered 
> > a couple of problems:
>
> Post some code. You even neglected to reveal 
> what GUI Toolkit you use!

Im using Smalltalk (VSE). Its a legacy system that we
have been enhancing and revitalizing recently. We put
in acceptance test first, and started unit testing.
Now I want to test the gui. There are a lot of badly
designed windows with a lot of domain logic tied up
inside, so the job is messy, but worth while. The
first thing I tried was to create a new open method
that didn't paint the window, and opend it up
non-modal. It went something like this.

    openForUnitTest
        self createViews.
        self dontPaint.
        self openModeless.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 19 Jun 2004 18:29
Picon
Favicon

[TFUI] Re: [XP] Hyperactive (or "Brittle"?) Tests

glew wrote:

> To avoid such brittleness, many of my tests are of
> the form:
> NOT
>      assertEquals("<strong><em>so
> what?</em></strong>", htmlResult);
> BUT
>     
>
assertRegexpMatch(".*<strong>.*</strong>.*",htmlResult);
>     
> assertRegexpMatch(".*<em>.*</em>.*",htmlResult);
>      assertEquals("so what?",stripXml(htmlResult));
> but this doesn't detect unbalanced <strong><em>so
> what?</strong></em>

    Fuzzy Matches
When esthetic graphic elements need tests, these might
require "wiggle room". Some tests for "red" should
pass "fuschia" or "magenta". As you develop, if a
hyperactive assertion fails, pick a fix from this
list:

* Remove the assertion
* Make the assertion match the code
* Make the code match the assertion
* Make the assertion fuzzy.

Don't make the assertion match the code, or vice
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 19 Jun 2004 19:21
Picon
Favicon

[TFUI] Mock Graphics

TFUI:

A "Mock Object" is a Test Fixture that tested
Production Code thinks is a real application object.
Imagine hunters placing decoys of ducks into a pond.
Real ducks obey their instinct to flock with things
that look like ducks. But decoy ducks have no meat
inside. Similarly, a test may construct a decoy that
looks like a real object, and place it into the pond
of production objects, to see how they interact with
it. But Mock Objects have little or no logic inside.

Some Mock Objects, in dynamic languages, automatically
generate any methods their clients request. In our
hunting parable, the ducks fly away, and the decoy
sprouts real wings to follow them. Some Mock Objects
take a reference to a real object, to mock all its
members. In our parable, a biomimetic decoy resembles
any required waterfowl.

If Production Code must call a sequence of methods on
the Mock Object, it can record each one in a Log
String, and the Test Case can then assert the sequence
was correct.

A Paint() event, to paint a custom control, or to
customize an existing control, typically dispatches a
sequence of graphics driver commands. To constrain
one, we must mock the graphics driver.
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 20 Jun 2004 17:35
Favicon

Re: [TFUI] Digest Number 158

TestFirstUserInterfaces@... wrote:

> Ideally, sloppy refactors that change the order of
> graphics commands, without changing appearances, would
> not fail these tests. Test Fixtures could interpret
> the commands and ensure the result still looks the
> same. But another fix for this problem is to not
> refactor sloppily. Remember to keep all your ducks in
> a row.

This is very, very nice, Phlip. Can you make sure that "not refactor 
sloppily" appears in bold, red print? Everywhere? Even here? :)
--

-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe@...

Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/TestFirstUserInterfaces/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phlip | 20 Jun 2004 18:05
Picon
Favicon

Re: [TFUI] Digest Number 158

J. B. Rainsberger wrote:

> TestFirstUserInterfaces@... wrote:
> 
> > Ideally, sloppy refactors that change the order of
> > graphics commands, without changing appearances,
> would
> > not fail these tests. Test Fixtures could
> interpret
> > the commands and ensure the result still looks the
> > same. But another fix for this problem is to not
> > refactor sloppily. Remember to keep all your ducks
> in
> > a row.
> 
> This is very, very nice, Phlip. Can you make sure
> that "not refactor 
> sloppily" appears in bold, red print? Everywhere?
> Even here? :)

Thanks. I know how to describe "hyperactive
assertions" now. They constrain changes that would not
have affected the end result, but are sloppy.

=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 24 Jun 2004 15:24
Picon
Favicon

[TFUI] RE: [XP] How much manual testing do you do?

Ilja Preuss wrote:

> Phlip wrote:
> 
> > Informal manual testing means collecting tactile
> > feedback from the integrated application.
> 
> Nice sentence - may I use it in the presentation? :)

Ja. Don't you attribute it, either.

> > If a test case surpresses a window, one can
> > temporarily configure the case to display the
> > window
> > instead of test it. This provides an excellent
> > platform for authoring, because the window arrives
> > in
> > a fully populated state, and you don't need to
> > drive
> > the app just to see that window with data in it.
> 
> That's what we did, too. We found that preserving
> the test scenario and
> giving it a more explicite place had some benefits,
> though.

I have been wondering who besides me might do that.
But I don't mean write the test case that only
displays the populated window. I mean a test case that
Assembles, Activates, and Asserts a test, and then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ilja Preuss | 25 Jun 2004 16:24
Favicon

[TFUI] RE: [XP] How much manual testing do you do?

Phlip wrote:

> But I don't mean write the test case that only
> displays the populated window. I mean a test case that
> Assembles, Activates, and Asserts a test, and then optionally
> displays the window. The test case remains online whether or not the
> window displays. 

I see. How do you configure wether the window is displayed? Do you
manually comment out a line, pass in a parameter or something?

> As you detect your own patterns of tweaking the window
> and (occassionally) manually testing it, you invest
> these discoveries into re-usable test functions. This
> leads directly towards test-first for GUIs. You can
> write entire tests blind, without displaying the
> window, by pulling in whatever re-usable test
> functions you have created for this intersection of GUI Toolkit and
> application. 

That's interesting - can you elaborate on what your reusable test
functions typically test?

Cheers, Ilja

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 25 Jun 2004 22:38
Picon
Favicon

[TFUI] Re: User Stories and the UI

[moved to another thread because the OP will need it.]

Ilja Preuss wrote:

> I see. How do you configure wether the window is
> displayed? Do you
> manually comment out a line, pass in a parameter or
> something?

I'm a programmer test-firsting a feature. I'm not in
the integrationist role, or the Quality Control role,
etc.

I want to see my window. The easiest way not to see it
is not call the method that dispatches events. For Tk
this method is mainloop(). For MS Windows it is
GetMessage() and DispatchMessage(). For Visual Basic
it is Show().

    Load frmMyForm
  frmMyForm.Initialize "my data"  '  <-- public method

    myDataBase.setSomeField("")

 frmMyForm.Submit_Click  '  <-- pretend to click on a
                         '        button

    Debug.Assert myDataBase.someField() = "my data"

    ' frmMyForm.Show 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ilja Preuss | 28 Jun 2004 19:41
Favicon

RE: [TFUI] Re: User Stories and the UI

Phlip wrote:

> We don't need to test that the Submit button itself is
> clickable. Refactoring won't easily change that. That logic
> is in the "GUI Toolkit" - we want to test only our own "GUI Layer".

Agreed, of course.

> Next, while programming a GUI we often want to look at
> its intermediate state. So I have a commented-out line
> that would have called 'Show' in Modal mode. It's
> Modal so we block all the other tests until we are
> finished looking at the window.

Ah, yes, that's what I wanted to know - thanks!

> If we see anything wrong we must decide to write a
> test, or to just fix it. If it's simple, such as two
> fields overlapping, just go to Design Mode and drag
> the fields apart. But if you don't know >why< the
> fields are overlapping, a test will help investigate.

Again, agreed.

>> That's interesting - can you elaborate on what your reusable test
>> functions typically test?
>
> [...]
> 
> Suppose the above test case wanted to send a low-level
(Continue reading)

Permalink | Reply | 0 comments |

Gmane