Very very nice :)

[sitefinitysteve]

Hey Devs, thanks so much for putting in the Conditional Logic and loops in the Gui...it's very very slick way to do it!

...and even better you give us extraction variables IN THE SAME RELEASE!  I've been waiting for this one for so long...


Ok, so along those lines can I ask an IF\ELSE validation question.  I want setup a "Login" test on a page I have...so I want to navigate to the login site (Login.aspx).  Now if I have a valid session it should send me over to Default.aspx, but if not then I should be at Login.aspx.

So how can I setup an IF\Else so that IF I see the Logout link, then I click it (and thus forcing me back to login.aspx where I can jsut have the test continue along normally entering the login info.

[Stoich]

Hi Steve,
  
    first off : thanks! Glad to hear you like the new features. Making our customers happy has always been our number one objective.

On your question: this is a bit more tricky than you might think. Let me give you the whole story:
The only way to check whether an element exists without using a coded step is by using the "Verify exists" statement. This step fails if the element in question can't be found.
 Now, when you create an IF statement using Conditional Logic from the GUI, you can add the "Verify exists" statement in this IF statement. You get a IF (Verify exists) statement which sounds like exactly what you need.  However, WebUI Test Studio doesn't change the way "Verify exists" behaves just because it's now inside an IF statement.
What this means: if the element doesn't exist - the step will fail. So your IF statement  will behave fine if the condition it's checking is true (the element exists). However, if the element doesn't exist : "Verify exists" fails and your whole IF step fails - and from there the test fails.
Using "Verify doesn't exist" has the opposite problem - the step (and from there the whole test) fails when the element does exist. 

You might be wondering why we decided to implement it like that. Well, the reasoning behind it is as follows:
 if your not careful when writing  your IF (Verify exists) statement, you might end up trying to invoke logic on an element that isn't there. So it's a trade-off: we protect our customers from NullPointer situations but we deprive them from GUI-based IF (element exists) statements.

The good news is we've decided to drop the "NullPoint protection" due to popular demand. So you'll be able to do your IF (Verify exists) checks exactly the way I described as non-working here. This will happen in an upcoming internal release - really soon.

Meanwhile, you will need to write your IF logic in a coded step. Write the Get Logic for an element or use the Get Logic which WebUI Test Studio will create for you automatically. After you "get" an element, your IF logic should be based on whether the element is Null (which would mean it doesn't exist). 

For a practical example: you want to navigate to page and login if and only if you're not currently logged in (pretty much your situation). So you write a coded step that will look something like this (in pseudocode):

Element ElementThatReadsLogin = Pages.YourPage.invokeGetLogic();
if (ElementThatReadsLogin != null) {
Pages.YourPage.inputYourCredentials("myUsr","myPass");
Pages.YourPage.Login();
}

 
This can be a single step in your test that you put in the very beginning. Again, this is pseudocode but you should be able to get the idea. Unfortunately at the moment you can't call regular steps from a coded step so you will have to write everything in your IF statement by hand. We've been getting lots of requests for this feature (calling regular steps from coded steps) so this is likely to change soon.

I hope I've managed to give you all the info you need. As always - ask away whenever something comes up.

And once again - thanks for the positive feedback!

Best Regards
Stoich
the Telerik team

[sitefinitysteve]

Oh good I can't wait for the next release then :)

btw, you wouldn't be able to tell me how to (from code behind) set an extraction var that can be used in the front end?

[Cody]

Hello Steve,

I have to ask what scenario do you have where you feel you need to set the value of an extraction variable in code to be consumed later by a regular test step? Why won't the normal extraction work in your scenario?

Unfortunately setting the value of an extraction variable cannot be done in code. Let us know what scenario you're trying to deal with and we'll try to come up with a working solution for you.

Best wishes,
Cody

the Telerik team

[sitefinitysteve]

Sending values grabbed from the DB into the frontend for validation...so like grab a username, then send that to the frontend to check it against more elements

If not doable I can keep it in the code, not a big deal :)

[Cody]

Hi Steve,

Why not use the data driven test feature? With a data driven test you have the ability to read all the values you want from virtually any data source (including a DB) and use that data as input (login name & password), etc.) or for verification steps (the text matches expected values, etc.). I am pretty sure you're already familiar with this feature. I just don't understand why it wouldn't work in this specific case?

Greetings,
Cody

the Telerik team

[sitefinitysteve]

I mean I've certainly seen the icons and options...but I'm not exactly sure what it is

You wouldn't be able to link me into some resources on the topic would you?

[Cody]

Hello Steve,

I would be very happy to! Give the attached document a read and let me know if you have any additional questions.

Regards,
Cody

the Telerik team