Having an alternative way of doing things might sometimes be great way to increase one’s own toolbox. At work having more than one tool to same work might sometimes come handy. This is something that actually inspired me to see another kind of world with testing, and all thanks should go to my innovating coacher who showed me a new way to do same thing with less work.
As in my previous post I had created as an example with robot framework, more than less they were data – and keyword driven. What I am going to show next, is something that is an alternative way to do same thing, although this is might be more suitable to understand without knowing much about coding and programming. The idea is to actually tell what we are going to do and execute the test case.
*** Settings ***
Library Selenium2Library
*** Test Cases ***
Scenario: Going to Google with Chrome in order to search about Robot Framework
Given I would like to go to "http://google.com" with "chrome"
Then I would like to search "Robot Framework"
Then I would like to close browser
*** Keywords ***
I would like to go to "${url}" with "${browser}"
open browser ${url} browser=${browser}
I would like to search "${browsing}"
Input Text name=q ${browsing}
Press Key name=q \\13
I would like to close browser
Close All Browsers
Basically what we are going to do here is that we have documented the test case in same time we have executed it. Also for business user this might be more understandable that the data driven version.
*** Settings ***
Library Selenium2Library
*** Variables ***
${url} http://google.com
${browser} chrome
${browsing} Robot Framework
*** Test Cases ***
Going to Google with chrome in order to search Robot Framework
[Documentation] Open the browser and input text. Lastly close the browser
open browser ${url} browser=${browser}
Input Text name=q ${browsing}
Press Key name=q \\13
Close All Browsers
Even thought they both do the same thing, one should always think which will service more purpose for the test case. If the test case is going to be created for more business like minded, the behavior typed test case might service more than the data driven version. Then if the whole idea is to test with chancing data as an technical minded could understand more, then the data driven could be better.
Behavior written test could also be a way to understand team-centric test cases where more than one department uses the same test case. This could be one way to access more cross-functional workflows and unite organization more. Business person could determinate how the system should response and developer might understand more why certain input creates certain output. This also add more collaboration and communication possibilities within departments if silos exists.
Tuomas Törmä 