Forgot to add that don't make any documentation about running tests just yet because i'm in the middle of making them runnable from the gems. And again, to point it out, my recommendation would be to make "configuring your browser" and "running tests" as part of an installation process and not anything separate.
Jarmo On Tue, Sep 28, 2010 at 1:06 AM, Jarmo <[email protected]> wrote: > On Tue, Sep 28, 2010 at 12:57 AM, Bret Pettichord <[email protected]> wrote: >>> It shouldn't be harder to run tests than to actually use the >>> lib thus having tests at some separate place and setting them >>> (separately) up isn't good option either. >> >> Right, but since you have to change the security settings for IE to get the >> test (only) to run, we break this rule no matter what. > > Ok, but if user wants to use Watir/FireWatir then they have to in the > end change their browser settings anyway nevertheless. Why not make it > part of an installation process in some documentation to avoid many of > those browser misconfiguration problems in the first place? In my view > it isn't different if user wants to use the library itself or wants to > run the tests (which are also using the library itself) because he/she > needs to make some configuration adjustments anyway in one way or > another. > >> >> The problem in the end is that our unit tests aren't really unit tests, and >> can't really meet all of these rules. The question, then, is which rules >> should we break? >> >> Maybe the solution would be to write some true unit tests and then package >> them with the gem? These would be tests that wouldn't actually fire up a >> browser, though, so although they would meet all of your rules, they would >> perhaps be less valuable. > > Agreed on the less valuable part. I still think that if user can run > unit-tests (or not THE unit tests, but the currently available tests) > then that means that his system is configured properly to use actual > library itself. There's no other point to have tests with the gem. If > there are runnable unit tests then we can always point users to run > them if there's some strange problems. > >> >>> Also, why do you think that Watirspec is a subset of Watir/FireWatir >>> tests? I can see it as a pretty good replacement of current tests. >>> Yeah, there are few functionalities which aren't tested by Watirspec >>> like #attach and #click_no_wait, >> >> Watirspec was created for Celerity. Therefore, I have assumed that it only >> included tests for features that are supported in Celerity. This means it >> omits support for such features as these. > > If you look at Watir-Webdriver, which uses also Watirspec then there > isn't that much of an API difference between Watir and (almost?) all > of the public API is covered with Watirspec. You may think of it as > all public methods are tested. > >> I was also able to use the Watir test suites to find a number of >> discrepancies between Watir and FireWatir. I don't believe the Watirspec >> suite can do this. It could, but it would need quite a bit of work first. > > Why not? Just run Watirspec against Watir and FireWatir - i'm pretty > sure there will be different failures... > >> >> Bret > > Jarmo > _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
