Smalltalk › Cincom › VisualWorks

Avoiding existing dialogs during SUnit testing

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Ken G. Brown

Avoiding existing dialogs during SUnit testing

What is the best way to avoid existing dialogs that pop up during SUnit testing?
This would be to enable the tests to be run more automatically.

Thx for any insight.

Ken G. Brown
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

jtuchel

Re: Avoiding existing dialogs during SUnit testing

Hi Ken,

I am not sure if you are referring to dialogs that your own code pops up
or ones that pop up in code that you have no control of.

My first advice would be to see if you can break the units for testing
down for the parts right before a dialog pups up and the parts that run
after. Often times, this is a lot less difficult than it seems to be.

If it is hard, it often has to do with the fact that the part before and
after share test data (test closure) and the parts after need some of
what happens before the dialog. If so, this still is a sign of a your
units being too coarse grained, but as a start you can try moving your
test closure from TestCase instance variables into TestResources. This
is dangerous, so please think about this very carefully, but it may be a
first step on your journey to doing it right.

But my main advice is really to break down your units and see if you can
test the parts before and after.

Another dirty and dangerous trick would be to teach dialogs to only open
themselves if some global state is not set to "TESTING". So you could
use some global variable that gets set to true when TestAsserters start,
and back to false when they finish. I wouldn't really recommend this,
but it may be better than giving up on tests.

HTH

Joachim

Am 26.02.13 20:33, schrieb Ken G. Brown:

> What is the best way to avoid existing dialogs that pop up during SUnit testing?
> This would be to enable the tests to be run more automatically.
>
> Thx for any insight.
>
> Ken G. Brown
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Randy Coulman

Re: Avoiding existing dialogs during SUnit testing

Ken,

In addition to Joachim's excellent advice, you can sometimes modify the dialog-raising code to take some kind of callback object. Your normal code would inject an object that makes the original dialog-raising calls, but your tests would inject an object that does nothing, records that the call was made, or responds with an appropriate response.

Randy

On Tue, Feb 26, 2013 at 11:50 AM, [hidden email] <[hidden email]> wrote:

Hi Ken,

I am not sure if you are referring to dialogs that your own code pops up or ones that pop up in code that you have no control of.

My first advice would be to see if you can break the units for testing down for the parts right before a dialog pups up and the parts that run after. Often times, this is a lot less difficult than it seems to be.

If it is hard, it often has to do with the fact that the part before and after share test data (test closure) and the parts after need some of what happens before the dialog. If so, this still is a sign of a your units being too coarse grained, but as a start you can try moving your test closure from TestCase instance variables into TestResources. This is dangerous, so please think about this very carefully, but it may be a first step on your journey to doing it right.

But my main advice is really to break down your units and see if you can test the parts before and after.

Another dirty and dangerous trick would be to teach dialogs to only open themselves if some global state is not set to "TESTING". So you could use some global variable that gets set to true when TestAsserters start, and back to false when they finish. I wouldn't really recommend this, but it may be better than giving up on tests.

HTH

Joachim

Am 26.02.13 20:33, schrieb Ken G. Brown:

What is the best way to avoid existing dialogs that pop up during SUnit testing?
This would be to enable the tests to be run more automatically.

Thx for any insight.

Ken G. Brown
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov, DeepCove Labs (SNN)

Re: Avoiding existing dialogs during SUnit testing

In reply to this post by jtuchel

On occasion, we've used the below when we were running across third-party code that couldn't be avoided,

| wrapper |

wrapper := Refactory.Wrappers.ConditionalMethodWrapper

on: #requestFileName:

inClass: Dialog class

alternative: [:a :b | (ObjectMemory imageDirectory \ 'hello.world') asString].

wrapper install.

[Dialog requestFileName: 'Hello?'] ensure: [wrapper uninstall]. ==> 'c:\visualworks\raven\hello.world'

You can find ConditionalMethodWrapper in 'Method Wrapper Examples' parcel and install/uninstall whatever wrappers you require in your tests' setUp/tearDown methods.

HTH,

-Boris

From: [hidden email] [mailto:[hidden email]] On Behalf Of Randy Coulman
Sent: Tuesday, February 26, 2013 3:01 PM
To: VW NC
Subject: Re: [vwnc] Avoiding existing dialogs during SUnit testing

Ken,

Randy

On Tue, Feb 26, 2013 at 11:50 AM, [hidden email] <[hidden email]> wrote:

Hi Ken,

I am not sure if you are referring to dialogs that your own code pops up or ones that pop up in code that you have no control of.

My first advice would be to see if you can break the units for testing down for the parts right before a dialog pups up and the parts that run after. Often times, this is a lot less difficult than it seems to be.

If it is hard, it often has to do with the fact that the part before and after share test data (test closure) and the parts after need some of what happens before the dialog. If so, this still is a sign of a your units being too coarse grained, but as a start you can try moving your test closure from TestCase instance variables into TestResources. This is dangerous, so please think about this very carefully, but it may be a first step on your journey to doing it right.

But my main advice is really to break down your units and see if you can test the parts before and after.

Another dirty and dangerous trick would be to teach dialogs to only open themselves if some global state is not set to "TESTING". So you could use some global variable that gets set to true when TestAsserters start, and back to false when they finish. I wouldn't really recommend this, but it may be better than giving up on tests.

HTH

Joachim

Am 26.02.13 20:33, schrieb Ken G. Brown:

What is the best way to avoid existing dialogs that pop up during SUnit testing?
This would be to enable the tests to be run more automatically.

Thx for any insight.

Ken G. Brown
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Randy Coulman

Email: [hidden email]

Home: http://randycoulman.com

Twitter: @randycoulman GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Samuel S. Shuster-2

Re: Avoiding existing dialogs during SUnit testing

In reply to this post by Ken G. Brown

Ken,

It depends on what raises the dialog.

For instance, in 7.8 and beyond, there are no inline Dialog calls in Store. Instead, dialogs are the defaultAction for exceptions, but if you on:do: the exception with a return: or resume:, the dialog won't open at all.

An example is how/if Store asks you if you attempt to publish the (none) package, which instead of having a Dialog warn: in the Store engine, raises the "NullPackageCanNotBeSaved" exception.

If you wanted to write a test to test if that code worked, you could write:

testNullPackageNotSave

| exceptionWasRaised |
exceptionWasRaised := false.
["some code that tried to save the (none) package"]
on: NullPackageCanNotBeSaved
do:
[:exception |
exceptionWasRaised := true.
exception resume].
self assert: exceptionWasRaised

The key to this is all about design decisions. If you never want to unit test code that could raise a dialog, or as elsewhere as noted by Boris, you are OK with using Method Wrappers, then you don't have to design for testability or reusability when you "hard code" dialogs in your system.

If it is your code, redesigning it for testing _may_ bring you better reusability later.

And So It Goes
Sames
______________________________________________________________________

Samuel S. Shuster [|]

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ken G. Brown

Re: Avoiding existing dialogs during SUnit testing

In reply to this post by Ken G. Brown

Thx to everyone for the tips.
I thought I would try Method Wrappers and accidentally saved my image with a wrapper as instance variable installed for Dialog warn:.
Uninstalling didn't seem to work at that point, and deleting the instance variable did not help.
How would I find the wrapper in order to clean it from the image?

I got to thinking that perhaps a global 'testingFlg' might be useful to be able to have the wrapper skip dialogs when testing but proceed normally when not.
It's not quite clear yet how I would implement that or if it would be a good idea, how would it be done?

Thx,
Ken

On 2013-02-26, at 1:04 PM, [hidden email] wrote:

> Date: Tue, 26 Feb 2013 20:04:12 +0000
> From: "Boris Popov, DeepCove Labs" <[hidden email]>
> To: VW NC <[hidden email]>
> Subject: Re: [vwnc] Avoiding existing dialogs during SUnit testing
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="us-ascii"
>
> On occasion, we've used the below when we were running across third-party code that couldn't be avoided,
>
> | wrapper |
> wrapper := Refactory.Wrappers.ConditionalMethodWrapper
> on: #requestFileName:
> inClass: Dialog class
> alternative: [:a :b | (ObjectMemory imageDirectory \ 'hello.world') asString].
> wrapper install.
> [Dialog requestFileName: 'Hello?'] ensure: [wrapper uninstall]. ==> 'c:\visualworks\raven\hello.world'
>
> You can find ConditionalMethodWrapper in 'Method Wrapper Examples' parcel and install/uninstall whatever wrappers you require in your tests' setUp/tearDown methods.
>
> HTH,
>
> -Boris

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov, DeepCove Labs (SNN)

Re: Avoiding existing dialogs during SUnit testing

Ken,

MethodWrapper nuke

HTH,

-Boris

-----Original Message-----
From: Ken G. Brown [mailto:[hidden email]]
Sent: Wednesday, February 27, 2013 10:58 AM
To: [hidden email]
Cc: Boris Popov, DeepCove Labs
Subject: Re: [vwnc] Avoiding existing dialogs during SUnit testing

Thx to everyone for the tips.
I thought I would try Method Wrappers and accidentally saved my image with a wrapper as instance variable installed for Dialog warn:.
Uninstalling didn't seem to work at that point, and deleting the instance variable did not help.
How would I find the wrapper in order to clean it from the image?

I got to thinking that perhaps a global 'testingFlg' might be useful to be able to have the wrapper skip dialogs when testing but proceed normally when not.
It's not quite clear yet how I would implement that or if it would be a good idea, how would it be done?

Thx,
Ken

On 2013-02-26, at 1:04 PM, [hidden email] wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ken G. Brown

Re: Avoiding existing dialogs during SUnit testing

In reply to this post by Ken G. Brown

Aha! Thx!
Ken

> Ken,
>
> MethodWrapper nuke
>
> HTH,
>
> -Boris
>
> -----Original Message-----
> From: Ken G. Brown [mailto:
> kbrown at mac.com
> ]
> Sent: Wednesday, February 27, 2013 10:58 AM
> To:
> vwnc at cs.uiuc.edu
>
> Cc: Boris Popov, DeepCove Labs
> Subject: Re: [vwnc] Avoiding existing dialogs during SUnit testing
>
> Thx to everyone for the tips.
> I thought I would try Method Wrappers and accidentally saved my image with a wrapper as instance variable installed for Dialog warn:.
> Uninstalling didn't seem to work at that point, and deleting the instance variable did not help.
> How would I find the wrapper in order to clean it from the image?
>
> I got to thinking that perhaps a global 'testingFlg' might be useful to be able to have the wrapper skip dialogs when testing but proceed normally when not.
> It's not quite clear yet how I would implement that or if it would be a good idea, how would it be done?
>
> Thx,
> Ken

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Niall Ross

Re: Avoiding existing dialogs during SUnit testing

Dear Ken,
method wrappers are my preferred solution.

My STIC 2007 talk (the conference was called Smalltalk Solutions in
those days) looked at this. (IIRC, you've got to download the whole
97Mb 2007 conference archive from the stic website to extract my slides
- which have lots of code on them - and my conference report, which
includes a detailed write-up of my talk.)

Some years back, I published examples to the open repository, e.g.
RBCustomBrowserUITests (which loads prereqs with more examples) but
these are for older releases - specifically VW 7.5.

(Internally, of course, we have vast numbers of tests, including
method-wrapper-using RB UI tests for the latest releases. If there were
interest in having these visible as how-to examples, it could be looked at.)

Yours faithfully
Niall Ross

>Aha! Thx!
> Ken
>
>
>
>>Ken,
>>
>>MethodWrapper nuke
>>
>>HTH,
>>
>>-Boris
>>
>>-----Original Message-----
>>From: Ken G. Brown [mailto:
>>kbrown at mac.com
>>]
>>Sent: Wednesday, February 27, 2013 10:58 AM
>>To:
>>vwnc at cs.uiuc.edu
>>
>>Cc: Boris Popov, DeepCove Labs
>>Subject: Re: [vwnc] Avoiding existing dialogs during SUnit testing
>>
>>Thx to everyone for the tips.
>>I thought I would try Method Wrappers and accidentally saved my image with a wrapper as instance variable installed for Dialog warn:.
>>Uninstalling didn't seem to work at that point, and deleting the instance variable did not help.
>>How would I find the wrapper in order to clean it from the image?
>>
>>I got to thinking that perhaps a global 'testingFlg' might be useful to be able to have the wrapper skip dialogs when testing but proceed normally when not.
>>It's not quite clear yet how I would implement that or if it would be a good idea, how would it be done?
>>
>>Thx,
>>Ken
>>
>>
>
>
>_______________________________________________
>vwnc mailing list
>[hidden email]
>http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ken G. Brown

Re: Avoiding existing dialogs during SUnit testing

Sounds good. I'll have a look.
Thx,
Ken,
from my iPhone

On 2013-02-28, at 14:16, Niall Ross <[hidden email]> wrote:

> Dear Ken,
> method wrappers are my preferred solution.
>
> My STIC 2007 talk (the conference was called Smalltalk Solutions in those days) looked at this. (IIRC, you've got to download the whole 97Mb 2007 conference archive from the stic website to extract my slides - which have lots of code on them - and my conference report, which includes a detailed write-up of my talk.)
>
> Some years back, I published examples to the open repository, e.g. RBCustomBrowserUITests (which loads prereqs with more examples) but these are for older releases - specifically VW 7.5.
>
> (Internally, of course, we have vast numbers of tests, including method-wrapper-using RB UI tests for the latest releases. If there were interest in having these visible as how-to examples, it could be looked at.)
>
> Yours faithfully
> Niall Ross
>
>> Aha! Thx!
>> Ken
>>
>>
>>> Ken,
>>>
>>> MethodWrapper nuke
>>>
>>> HTH,
>>>
>>> -Boris
>>>
>>> -----Original Message-----
>>> From: Ken G. Brown [mailto:
>>> kbrown at mac.com
>>> ] Sent: Wednesday, February 27, 2013 10:58 AM
>>> To: vwnc at cs.uiuc.edu
>>>
>>> Cc: Boris Popov, DeepCove Labs
>>> Subject: Re: [vwnc] Avoiding existing dialogs during SUnit testing
>>>
>>> Thx to everyone for the tips.
>>> I thought I would try Method Wrappers and accidentally saved my image with a wrapper as instance variable installed for Dialog warn:.
>>> Uninstalling didn't seem to work at that point, and deleting the instance variable did not help.
>>> How would I find the wrapper in order to clean it from the image?
>>>
>>> I got to thinking that perhaps a global 'testingFlg' might be useful to be able to have the wrapper skip dialogs when testing but proceed normally when not. It's not quite clear yet how I would implement that or if it would be a good idea, how would it be done?
>>>
>>> Thx,
>>> Ken
>>
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ken G. Brown

Re: Avoiding existing dialogs during SUnit testing

I'm having a hard time finding the 2007 conference archive. Any of you packrats out there have the archive lurking around somewhere, or does anyone have a working link?
The STIC site doesn't appear to have the 2007 archive, but I've sent them an email to see if they have it anywhere.

Thx,
Ken

On 2013-02-28, at 2:50 PM, Ken G. Brown wrote:

> Sounds good. I'll have a look.
> Thx,
> Ken,
> from my iPhone
>
> On 2013-02-28, at 14:16, Niall Ross <[hidden email]> wrote:
>
>> Dear Ken,
>> method wrappers are my preferred solution.
>>
>> My STIC 2007 talk (the conference was called Smalltalk Solutions in those days) looked at this. (IIRC, you've got to download the whole 97Mb 2007 conference archive from the stic website to extract my slides - which have lots of code on them - and my conference report, which includes a detailed write-up of my talk.)
>>
>> Some years back, I published examples to the open repository, e.g. RBCustomBrowserUITests (which loads prereqs with more examples) but these are for older releases - specifically VW 7.5.
>>
>> (Internally, of course, we have vast numbers of tests, including method-wrapper-using RB UI tests for the latest releases. If there were interest in having these visible as how-to examples, it could be looked at.)
>>
>> Yours faithfully
>> Niall Ross
>>
>>> Aha! Thx!
>>> Ken
>>>
>>>
>>>> Ken,
>>>>
>>>> MethodWrapper nuke
>>>>
>>>> HTH,
>>>>
>>>> -Boris
>>>>
>>>> -----Original Message-----
>>>> From: Ken G. Brown [mailto:
>>>> kbrown at mac.com
>>>> ] Sent: Wednesday, February 27, 2013 10:58 AM
>>>> To: vwnc at cs.uiuc.edu
>>>>
>>>> Cc: Boris Popov, DeepCove Labs
>>>> Subject: Re: [vwnc] Avoiding existing dialogs during SUnit testing
>>>>
>>>> Thx to everyone for the tips.
>>>> I thought I would try Method Wrappers and accidentally saved my image with a wrapper as instance variable installed for Dialog warn:.
>>>> Uninstalling didn't seem to work at that point, and deleting the instance variable did not help.
>>>> How would I find the wrapper in order to clean it from the image?
>>>>
>>>> I got to thinking that perhaps a global 'testingFlg' might be useful to be able to have the wrapper skip dialogs when testing but proceed normally when not. It's not quite clear yet how I would implement that or if it would be a good idea, how would it be done?
>>>>
>>>> Thx,
>>>> Ken
>>>
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc