Re: [Watinfixture-users] Not closing the browser leaves Fitnesse"running"

[Jeff P. <ka...@iw...>]

Rob,

 

If you like WatiN, make sure to send Jeroen van Menen an email with kudos.
He built WatiN, and I think it is a fantastic testing tool.  WatiNFixture
needs a lot more growth in the petrie dish before it gets anywhere near as
good as WatiN.

 

>> "When gawking through your code I saw you using a threadslot thingy to
hold an instance of WatiN's IE... as opposed to a simpler singleton... I was
wondering why you went that route?"

 

I think that was the only way I could think of to implement a Singleton that
would be useable across commands.  There's probably a better way to do that.
Basically, I wanted the browser to be opened at the start of the test, work
for any test fixture you threw at the page, and then close at the end.
Because some fixtures are destroyed when their test table is done (and have
to be redeclared at the top of every test table), the browser wouldn't be
guaranteed to exist - the Singleton may have been inadvertently disposed.

 

>> Any recommendations in regards stability in doing my own custom fixtures?

 

The best recommendation I have is to do test driven development.  Write a
few tests, write some code, make sure everything works, then continue on to
the next step.  Refactor as you go.  That way you won't write a large test
and then get plagued with problems.

 

Also, it depends on what you're trying to do that is causing COM/interop.  I
know when I was trying to check styles using the HTMLElement class (which
jumps into the Microsoft.mshtml.dll), I would occasionally hit an object
during testing where the HTMLElement that came back (or that I was trying to
reference) was defined as a COM object.  You might put your code into debug
mode and test it.

 

Jeroen later added the Style class to WatiNFixture, so I could take that
element out.

 

If your debug shows that, then you could add if statements to look for it
and gracefully handle the problem.

 

My personal recommendation, though, is to stay away from anything in
Microsoft.mshtml and try to use WatiN for what you need.  It's a great tool,
and I haven't needed to use Microsoft.mshtml for any of my fixtures except
for the brief time I was using them for styles - so I could test those silly
Microsoft validators.  They're always there to be found, the only way to see
whether they are shown or hidden is to check the Visibility style.

 

>> I also seemed to have no end of difficult with working with dropdowns and
Select

 

For this, check what I did in the HasItemSelected selected method for
DropDownListHandler.  One item to look for is if either your select list or
the table you're using has spaces on the end.  You may be looking for the
exact text, but the select box has <listitem>Orange
</listitem>.  The way I handled that was to have the compare operation
automatically trim the whitespace off the end, as it's probably something
you don't need to check for.

 

I did not do a Trim() on the string, as I ran into tests where the users
wanted to check for items with leading spaces.

 

>> debugging "front to back" from VS2005 working

 

I found an article somewhere that explained how to debug FitNesse fixtures
from Visual Studio.  I can't remember where I found it, but I remember that
when I figured it out, it was a great help to debugging.  I'd keep pursuing
that.

 

Jeff

 

  _____  

From: Rob MacFadyen [mailto:rma...@rm...] 
Sent: Tuesday, September 11, 2007 11:24 PM
To: 'Jeff Parker'; wat...@li...
Subject: RE: [Watinfixture-users] Not closing the browser leaves
Fitnesse"running"

 

Jeff,

 

I've been "mixing and matching". I started writing my own... thinking it
would be cool to offer a bridge framework that "talked" my application...
fixtures for creating "code tables" and fixtures for creating "code
values"... rather than doing this with WatiNFixture.

 

but... that's been relatively short lived... lots of weird problems... 

 

So... I figured it was time to "back up"... and now I'm using WatiN. So far
it's showing itself to be much more stable than my attempts (and pretty
cool... nicely done). 

 

Any recommendations in regards stability in doing my own custom fixtures? I
take it that there's some funky COM/interop weirdness that's causing things
to "hang" if the browser is not closed... any opinion? When gawking through
your code I saw you using a threadslot thingy to hold an instance of WatiN's
IE... as opposed to a simpler singleton... I was wondering why you went that
route?

 

I also seemed to have no end of difficult with working with dropdowns and
Select... exceptions about not finding values... when they clearly are
there. And some of these "sorts of exceptions" seemed to result in Fitnesse
"hanging"... very frustrating... especially since I don't seem to have quite
worked out how to get debugging "front to back" from VS2005 working.

 

Ah... I see the sleep command... that will do nicely.

 

Thanks a ton!

 

Regards,

 

Rob

 

 

  _____  

From: Jeff Parker [mailto:ka...@iw...] 
Sent: September 12, 2007 12:07 AM
To: 'Rob MacFadyen'; wat...@li...
Subject: RE: [Watinfixture-users] Not closing the browser leaves
Fitnesse"running"

Did you develop your own custom FitNesse wrapper for WatiN?

 

If you did, go get my project, WatiNFixture.  One of the fixtures I wrote
was a custom Pause with a timeout setting.  You can see how I did that and
adopt the code into your own.

 

  _____  

From: wat...@li...
[mailto:wat...@li...] On Behalf Of Rob
MacFadyen
Sent: Tuesday, September 11, 2007 8:36 PM
To: wat...@li...
Subject: [Watinfixture-users] Not closing the browser leaves
Fitnesse"running"

 

Hi,

 

If I setup a few simple UserAction test steps and do not finish the test
with "close browser" the browser display the Fitnesse results will remain
"waiting for http://localhost:8080/WatiN01?test...." (I'm running fitnesse
on port 80, my test script is called WatiN01). And further the FitServer.exe
process remains running indefinately.

 

The reason I'm not closing the browser is that I need to see what's going
on. I have a Verify Browse Navigated To that is failing... and I really need
to see the web page so I can tell what's happening. If I put the "close
browser" step in... well... the browser is gone so quickly all I can tell is
that I have some sort of an application error message being displayed.

 

Any suggestions? Any way to put a "pause" of some sort in there?

 

Regards,

 

Rob