Hey, I've got an idea: why have humans even review
the test results? I mean, that's just a suggestion that the script can't
fix whatever problem is in the code that's under test, right? In fact, why
have humans write the test scripts at all? That really smells like we need
humans involved
Hi Scott
I tried to run the following
ie_array = Array.new(3)
ie0 = WIN32OLE.new('Shell.Application')
system c:\\Program Files\\Internet Explorer\\iexplore.exe
ie0 = IE.attach(:title,'Google') #my IE default page is Google
ie0.goto(http://localhost:8080/kmdm8/signon.jsp;)
I tried to run the following
ie_array = Array.new(3)
ie0 = WIN32OLE.new('Shell.Application')
system c:\\Program Files\\Internet Explorer\\iexplore.exe
ie0 = IE.attach(:title,'Google') #my IE default page is Google
ie0.goto(http://localhost:8080/kmdm8/signon.jsp;)
ie_array[0] = ie0
Hi,
I have a class for each automated test, and each application window or any
other related group of functionality is in a module.
Here is an example of a test class:
require 'all_libs'
class ST_LTD_6
def run
begin
p TESTID: #{self.class}, TEST DESCRIPTION: Change View Type
Sorry if I came across a little too harsh, I'm blaming the heat, it's been 90s here for the past week. :) Maybe I'll try to actually be helpful now that I've fallen off my high horse and knocked my head. If your lag time for server cert acceptance is as much as 24 hours and variable within that,
Sorry if I came across a little too harsh, I'm blaming the heat, it's been
90s here for the past week. :) Maybe I'll try to actually be helpful now
that I've fallen off my high horse and knocked my head.
It's alright. I agree that in normal cases, automated testing should
be, well, automated.
This isn't a bug in Watir, so the BUG: title for your message isn't
appropriate. There are lots of bugs here, but they ain't in Watir.
Does your script include 'require watir.rb' and 'include Watir' at any
point?
When you try to attach using a string literal, it's unlikely to work for
attaching
here is a wrapper
for Watir scripts that I briefly looked at, gives you the ability to run
Watir tests through Nant, so you should be able to get more of a continuous
integration environment:
http://dustin.homestead.com/files/blogs/2006/02/integrating-watir-into-nant-and-nunit.html
It looks
I've been using that as well for xUnit style reporting. Highly recommended to make for nice testing reports in Cruise Control or otherwise. Just out of curiousity what changes did he make? It's been a few years since the release.
-CharleyOn 6/6/06, Chris McMahon [EMAIL PROTECTED] wrote:
here is a
On 6/6/06, Charley Baker [EMAIL PROTECTED] wrote:
I've been using that as well for xUnit style reporting. Highly recommended
to make for nice testing reports in Cruise Control or otherwise. Just out of
curiousity what changes did he make? It's been a few years since the
release.
I've lost the
There's another issue which may be affecting your test that is also NOT
a Watir bug.
Sessions are often set by having a server save a session ID cookie on
the IE's PC. For IE, these cookies are saved in a per-user directory.
If you run multiple IE's to the same site then the cookies can be
That's a good point if cookies are involved, for sure. Even when they're
not involved, there can be some weirdnesses, too. I remember that Firefox's
behaviour, in terms of session ID, is different; I don't remember how it's
different, though.
---Michael B.
-Original Message-
From:
Has anyone else experienced a slowdown of their applications since
updating Watir from 1.4.1 to 1.5.0.1026?
Is there some kind of background polling going on that is slowing things
down? Because my application performance has slowed down by about half.
Lonny Eachus
==
On 6/6/06, Lonny Eachus [EMAIL PROTECTED] wrote:
Has anyone else experienced a slowdown of their applications sinceupdating Watir from 1.4.1 to 1.5.0.1026?Is there some kind of background polling going on that is slowing thingsdown? Because my application performance has slowed down by about half.
On 6/1/06, Tyler Prete [EMAIL PROTECTED] wrote:
I can't provide the full html because I don't have access to it, but here is the link I am trying to click from the popup:a href='' target='cust' 8560113/aI imagine part of the problem is related to the onclick _javascript_ event, however I did try
Support Requests item #4681, was opened at 2006-06-06 20:15
You can respond by visiting:
http://rubyforge.org/tracker/?func=detailatid=488aid=4681group_id=104
Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Tom Copeland (tom)
Assigned to: Nobody (None)
Summary:
Our group has also found that global variables can carry over between
separate runs of the same application, probably due to server caching.
If a global variable was set during one run of the application, and not
explicitly set to something else on the next run, then it would (often?
always?)
Thanks for the input. It could be due to something else, which is why I
was asking.
Lonny Eachus
=
Subject:
Re: [Wtr-general] Watir 1.5.x Performance Issues?
From:
"Bret Pettichord" [EMAIL PROTECTED]
I am planning to add multiple attribute support to Watir. For example: ie.div(:class = MenuItem, :text = Pulverize).click The old syntax would continue to be supported.
ie.div(:text, Pulverize).clickMoreover, you could now also specify single attributes using this newhash syntax. Thus:
YES!!
Up until now, I have been a lurker on this list who could not use Watir--the
main application that I support requires that I be able to use multiple
attributes to specify a control.
Andrew McFarlane
From: Bret Pettichord [EMAIL PROTECTED]
Reply-To: wtr-general@rubyforge.org
To:
Hi Bret,Can't XPath functionality be used to access elements using multiple attributes? This is already there.
ie.div(:class = MenuItem, :text = Pulverize).clickThis translates to:ie.div(:xpath, //[EMAIL PROTECTED] = 'MenuItem' and @text = 'Pulverize']).clickI think XPath provides much more
On 6/6/06, Angrez Singh [EMAIL PROTECTED] wrote:
Can't XPath functionality be used to access elements using multiple attributes? This is already there.
ie.div(:class = MenuItem, :text = Pulverize).clickThis translates to:ie.div(:xpath, //[EMAIL PROTECTED] = 'MenuItem' and @text =
On 6/6/06, Lonny Eachus [EMAIL PROTECTED] wrote:
Our group has also found that global variables can carry over between
separate runs of the same application, probably due to server caching.
If a global variable was set during one run of the application, and not
explicitly set to
xpath is also very unreadable.
As a side note, one of my clients has recognized
the value of good html. When something is missing an id , we add an hour, per
build,per testcasefor manual testing of the application. It
something that is now easy for the developers and project managers to see
24 matches
Mail list logo
