Run keyword if test has a specific tag

[cn...@mywebgrocer.com]

Hiya,

Is there possibility to to something like:

Run Keyword If Test Has Tag        mobile

As what i want to do is tag my UI tests as {desktop, tablet, mobile} and in the (common) TestSetup keyword conditionally execute keywords to setup the browser to the correct screensize (for example)

Thanks,
Clayton

[Navotna]

The current tags are available as a built-in variable @{TEST TAGS}.
So you can check: is tag in test tags.

[Tatu Aalto]

Ugh

I have seen some other people also asking for the same feature. Perhaps you should raise issues about it and perhaps someone will send a pull request. With a quick thinking, this could be useful and relatively easy to write.

-Tatu
Send from my mobile

On 20 Aug 2015 8:19 am, "Navotna" <a.los...@gmail.com> wrote:

The current tags are available as a built-in variable @{TEST TAGS}.
So you can check: is tag in test tags.

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at http://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

[Ed Manlove]

I've been wandering and pondering the question of whether the new in 2.9 keyword tags can be used like the test cases tags to include or exclude certain keywords. My reason for doing so would be differentiate and prioritize various validation keywords. "Let me run these sets of validation keywords" or "I just want to check these items" type of execution. Here it would be the same series of test steps but sometimes I would be checking everything and other times just a select set of (keyword) validations. Note I would apply this to my own validation keywords.

I am sure there are other ways but was just thinking about this lately...

Ed

[devP...@verizon.net]

On Monday, August 24, 2015 at 7:09:22 AM UTC-4, Ed Manlove wrote:

I've been wandering and pondering the question of whether the new in 2.9 keyword tags can be used like the test cases tags to include or exclude certain keywords. My reason for doing so would be differentiate and prioritize various validation keywords. "Let me run these sets of validation keywords" or "I just want to check these items" type of execution. Here it would be the same series of test steps but sometimes I would be checking everything and other times just a select set of (keyword) validations. Note I would apply this to my own validation keywords.

I am sure there are other ways but was just thinking about this lately...

Ed

I want to circle back on this idea of using keyword tags as a method for excluding keywords from execution. My reason for this functionality is still the same as I wrote above. I want to create a test case that has several sets of validations and layers of validation for which I might at various times not want nor need to make/run all those validations. I want a single test case but may have different contexts in which I run it and thus want various keywords not to execute. This concept of context test running was well described by Denali Lumma in her 2015 Selenium Conf talk entitled "2020 Testing" [1].

Pekka, Tatu, others... what do you all see as the technical challenges for implementing such a functionality? I understand there is always resource restrictions so that may be a much bigger factor so really focused on the technical aspects. Also I understand this may also not be desirable functionality from the community or RF road map standpoint so if so please share those thoughts too.

Ed

[1] https://www.youtube.com/watch?v=y6zPm278YGQ

[Pekka Klärck]

Hello,

I'm not totally convinced by this idea, but I'm not really against it
either. Probably I just haven't really understood it correctly. Could
you show a concrete, but preferably simple, example how it could be
used? If we agree it's useful and can also agree on the design, then
it's just up to someone to write a pull request.

Cheers,
.peke

> --
> You received this message because you are subscribed to the Google Groups
> "robotframework-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to robotframework-u...@googlegroups.com.
> To post to this group, send email to robotframe...@googlegroups.com.

> Visit this group at https://groups.google.com/group/robotframework-users.

>
> For more options, visit https://groups.google.com/d/optout.



--

Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Bryan Oakley]

Are you asking how to exclude a block of keywords from a single test? Why do you want one big mega-test with a bunch of configurations rather than a suite of smaller tests? There's already the ability now to exclude whole tests (assuming you can decide what you want to do before the test start). Can't you just break your one big test into a bunch of smaller tests, and then include or exclude the tests based on tags? 

          

--

You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.
To post to this group, send email to robotframework-users@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.

[Vara]

You can use variables to achieve this. Those can be passed from command line also.

Run keyword if '${ENV}'=='Mobile' keyword1 like that...

[Paolo Mondelo]

try tagging the test case with any tag and on the command line execute it by using -e *name of tags. 

Test Case

[Tags]    TRIAL

Keyword

Keyword 

[Kevin O.]

I have given this some thought and I feel like the cure is in fact no better than the disease.

From the Zen of Python:

Explicit is better than implicit.

So I run this test and Check Bar is skipped due to tags?

I think using tags to skip KW execution is hiding the complexity that would be better to be explicit about.

Also there is the psychological aspect of it. The proposal essentially breaks the contract of a keyword doing what it "says" it is doing.

Test Foo

    Check Bar

Check Bar

    [Tags]    extra_checks

    Should Be True    ...

Perhaps I a missing something though?

Kevin

[devP...@verizon.net]

The key here is I am doing the same things, performing the same actions in my application, but just want different levels of verification. Here is the example I like use when trying to illustrate

*** Keywords ***
Take Step
  [Arguments] ${foot}
  Move ${foot} Foreward
  Verify ${foot} moved

Walk ${N} Steps Foreward
  Take Step  ${nextfoot}
  Verify My Position Is Not Where I Once Was

Turn ${Degrees} ${Counter/Clockwise}
  ...
  Verify View is Different Than Before


*** Keywords ***
Verify ${foot} moved
[Tags]  Level 3

Verify My Position Is Not Where I Once Was
[Tags]  Level 2

Verify View is Different Than Before
[Tags]  Level 2

Verify I Am At My Destination
[Tags]  Level 1


*** Test Case ***
Walk Around The Office
  Get Up From Desk
  Walk To The Training Room
  Walk To The Conference Room
  Walk To The Front Desk
  Walk To My Desk

Walk From Desk To Conference Room
  Get Up From My Desk
  Turn to the Left
  Walk Forward 7 Steps
  Turn to the Right
  Walk Forward 4 Steps
  Turn to the Left
  Walk Forward 25 Steps
  Turn to the Right
  Walk Through the Doorway
  Verify I Am In The Conference Room

So I have a set of test cases and depending on the context I will verify only the high level or important checks ("Did I make it to my destination?"). Or I may want to check level 2 or level 3 items ("Was each step taken?"). The assumption here is that there is a cost to the validations and so I may want to check all the low level validations or I may just want a high level validation. The key here, and I feel it is an important distinction, is that I am doing the same things within each test.

I don't believe this to be a single large mega-test nor am I suggesting such. One mammoth test is, to me, a RED FLAG that you are doing something wrong. I do feel it is important that you call this out so I hopefully highlight the differences. This is more contextual testing where you a repeating a specific series of test steps but have different validation viewpoint each time. Once again I think Denali Lumma calls out the need for contextual testing well in her 2015 Selenium Conference talk "2020 Testing" [https://www.youtube.com/watch?v=y6zPm278YGQ]. If you forward to 0:48 through to 02:40 minutes into her talk and then again from 19:06 to 19:27 you will get her insight into this need.

As Vara suggested I could use a variable. I'll will say I prefer to hide this type of logic at lower levels for test readability reasons. So instead of seeing the test look like

*** Test Case ***
Walk From Desk To Confernece Room
  Get Up From My Desk
  Run Keyword If  ${performLevel2}  Validate I Have Gotton Up From My Desk
  Turn to the Left
  Run Keyword If  ${performLevel2}  Validate I Have Turned To My Left
  Take a Step
  Run Keyword If  ${performLevel3}  Verify Left Foot Moved
  ...
  Run Keyword If ${performLevel1}  Verify I Am In The Conference Room

I prefer to use Return From Keyword If to hide these within the keywords looking more like

*** Keywords ***
Validate I Have Turned To My Left
  Return From Keyword If  ${ignoreLevel2}
  ...
 
Verify Left Foot Moved
  Return From Keyword If  ${ignoreLevel3}
  ...

Verify I Am In The Conference Room
  Return From Keyword If  ${ignoreLevel1}
  ...

I guess it it this desire to push down as far as possible this logic and hide it as my reason for seeing this go into the framework. But I also see your arguments that this essentially breaks the contract of the keyword.

Ed

[Wlad]

@devPyPITW  Looking at your show case I'd say you need the validation steps regardless of the context the test is executed in. BUT I would distinguish between "keyword validation steps" and the actual "test case verification step(s)" . Thus regarding your demo I would have e.g. "Validate I Have Turned To My Left" be part of "Turn to the Left" keyword's definition instead of being a step of the test case. As "Verify I Am In The Conference Room" is what decides whether the test passes or fails this can remain as separate keyword inside the test case . May be it's a good idea  to stick to a naming convention e.g.  use VALIDATE on keyword level and VERIFY on test case level only ... just an idea. I think in general a (automated) test cases should be as easy as possible and very specific, they should avoid to have any logic or any magic else you might end up in maintenance nightmare. 

If you still want to reuse same test case for different "performLevels" then you keywords may look like this
(assuming performLevel 1 means highlevel only, 2 is something in between and 3 means validate everything)

*** variables ***

${performLevel}    1    # default validation: high level only

*** keywords ***

Get Up From My Desk

     action 1

     action 2

     ...

     Run Keyword If    "${performLevel}>=1"    Validate I Got Correct Response Code     # this validation will be executed at any performLevel
     Run Keyword If    "${performLevel}>=2"    Validate I Have Gotton Up From My Desk    # will not be validated per default

     Run Keyword If    "${performLevel}>=2"    Validate My Feets Touch The Ground

     Run Keyword If    "${performLevel}==3"    Validate My Shoes Have Not Changed Their Color    # validate @performLevel 3 only

Turn to the Left

     action 1
     action 2
     ...

     Run Keyword If    "${performLevel}>=1"    Validate I Got Correct Response Code     # this validation will be executed at any performLevel
     Run Keyword If    "${performLevel}>=2"    Validate I Have Turned To My Left

     Run Keyword If    "${performLevel}==3"    Validate I Have Turned My Head Too

Your Test Case keeps unchanged. Now you can alter performLevel pro execution from command line:

robot --variable performLevel:3  your_file_name.robot   --> this will validate everything from high to low level

robot your_file_name.robot   --> this will execute with performLevel==1, thus high level validation only

Cheers

Tset

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.

[Pekka Klärck]

Hi Ed,

Have you considered implementing these keywords in different resource
files or libraries and importing them conditionally? You could have,
for example, resource files level-1.robot, level-2.robot and
level-3.robot and import the right resource file like this:

*** Settings ***
Resource level-${LEVEL}.robot

You can specify the default value for ${LEVEL} in the variable section
or require that it's always passed from the command line.

Cheers,
.peke

> --
> You received this message because you are subscribed to the Google Groups
> "robotframework-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to robotframework-u...@googlegroups.com.
> To post to this group, send email to robotframe...@googlegroups.com.
> Visit this group at https://groups.google.com/group/robotframework-users.
> For more options, visit https://groups.google.com/d/optout.