Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

Is there an way to have Assert and/or Should not stop if it fails?

#2

---------- Forwarded message ---------- From: cernenus_1 sqapro@gmail.com Date: Mon, Mar 30, 2009 at 12:30 PM Subject: [watir-framework] Is there an way to have Assert and/or Should not stop if it fails? To: watir-framework@yahoogroups.com

I can see how when you are doing outside in development work, you want your stuff to stop at the first step that's not working.

OTOH when you are running a suite of tests for things like regression tests, and you have steps that have multiple validations, e.g. you have


  THEN xxxx happens
  AND  yyyy also happens
  BUT I don't see zzzz

it would really be nice in the test results to know the status of the other two items if xxxx fails, especially in cases where xxx failing does not preclude the ability to check on the other two, and even more so in cases where seeing zzzz fail would give you a clue as to what went wrong.

Consider for example a scenario of logging out user a and logging in user b, and you are checking that you don't still see user a logged in. Or a scenario dealing with security and combining permissions of multiple roles where you have multiple validations needed to ensure that the system is giving you the right result of the combined permissions.

That or if it can't proceed to the other tests, it would be nice to report them as 'blocked' so we know that it's not that they failed or passed, but that we don't KNOW their status because we couldn't get there.

Reported by bret (at watircraft) · March 31st, 2009 @ 02:24 PM

State: open
Milestone: Backlog
Assigned to: Bret Pettichord Bret Pettichord

Activity

  1. bret (at watircraft)
    bret (at watircraft)
    • State changed from new to open

    This is a good suggestion. We've had people ask about this before. As a comparison, the "verify" method in Watir::TestSuite provides this functionality.

    March 31st, 2009 @ 02:26 PM

  2. bret (at watircraft)
    bret (at watircraft)
    • Assigned user set to bret (at watircraft)

    March 31st, 2009 @ 04:23 PM

  3. bret (at watircraft)
    bret (at watircraft)
    • Milestone set to Backlog

    Moving to backlog. Note that this won't be easy, and therefore probably won't be done soon.

    April 7th, 2009 @ 12:13 AM

  4. Chuck van der Linden
    Chuck van der Linden

    Potentially I wonder if perhaps this is better raised with the Rspec/Cucumber folks?? since we'd be talking about changing the basic way that .should operates.

    April 8th, 2009 @ 04:06 PM

  5. bret (at watircraft)
    bret (at watircraft)

    You are welcome to bring it up with the Rspec folks. It would require changing the way "should" works.

    One alternate idea i've considered would be to create a new modal verb -- maybe "shall" -- and attach the new behavior to it.

    Bret

    April 8th, 2009 @ 04:27 PM

  6. bret (at watircraft)
    bret (at watircraft)

    You've raised this issue before and we've discussed it on this ticket. http://watircraft.lighthouseapp....

    It would probably take me a couple of hours to research this and determine whether it would be hard or not.

    Bret

    On Wed, Apr 22, 2009 at 7:05 PM, chuckvdl sqapro@gmail.com wrote:

    Is there a way that the framework could provide us with an alternative to .should that is similar to the 'verify' alternative that watir provides for 'assert'?

    Something that would work like .should does, e.g. with the matchers and read nicely to make very clearly worded steps and tests? But would also keep going and do any other following validations in the same test? (and work with cucumber and rspec)

    I I can't think of a really good name, the best I can come up with would be .ought , .oughtto , or .ought_to

    Then again, I suppose in the spirit of my wife's detesting it when she finds the word 'should' in specs ("it should? well when shouldn't it? when wouldn't it? what happens if it doesn't?") I ought perhaps suggest the use of '.will' to indicate the behavior expectation is in no way fuzzy..

    Yeah, I guess that works.. lets see

    browser.element(attrib, 'value').will exist

    yes, that's pretty clear isn't it?

    would that be an easy doable thing, or a major non-trivial undertaking?

    Yahoo! Groups Links

    <*> To visit your group on the web, go to: http://groups.yahoo.com/group/wa...

    <*> Your email settings: Individual Email | Traditional

    <*> To change settings online go to: http://groups.yahoo.com/group/wa... (Yahoo! ID required)

    <*> To change settings via email: mailto:watir-framework-digest@yahoogrou... mailto:watir-framework-fullfeatured@yah...

    <*> To unsubscribe from this group, send an email to: watir-framework-unsubscribe@yaho...

    <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

    -- Bret Pettichord CTO, WatirCraft LLC, www.watircraft.com Lead Developer, Watir, www.watir.com

    Blog, www.io.com/~wazmo/blog http://www.io.com/%257Ewazmo/blog Twitter, www.twitter.com/bpettichord GTalk: bpettichord@gmail.com

    Ask Me About Watir Training www.watircraft.com/training

    -- Bret Pettichord CTO, WatirCraft LLC, www.watircraft.com Lead Developer, Watir, www.watir.com

    Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord GTalk: bpettichord@gmail.com

    Ask Me About Watir Training www.watircraft.com/training

    April 22nd, 2009 @ 11:29 PM

  7. Bret Pettichord
    Bret Pettichord
    • Assigned user changed from bret (at watircraft) to Bret Pettichord

    [responsible:ID#38130 bulk edit command]

    June 11th, 2009 @ 09:00 PM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.