Xamarin UI Tests – Deep dive Part 3

Testing to a next level 

To improve applications testing a great focus on the business and requirement needs was approached, and thus it came to be to write the tests first and thus forcing the developer to write the code the will run this test successful, though this may have added a great value to testing, still the idea of developers deviating from the main business scope and going their way still make a huge margin, so in order to improve TDD a new approach came to be, BDD is an approach that allows the interchangeability between business language and developers language, so it allows business owners to write readable test cases that can be read by any business owner or non technical, using natural language, and in even different languages not necessarily English, that developers can map to actual coded tests they develop, and thus giving more emphasis on the whole business needs values,

BDD in Xamarin 

As illustrated before we will be using specflow to run the tests and we are going to use the project that we used to conduct the usual UI tests to user BDD, so how does it work ?

Previously when we did the tests it was page specific for instance if we wanted to test the login page we would start with something like LoginPageTests, however that is not the case in BDD as our main driving focal is the business so we start our tests in BDD with a feature 

a feature is a simple natural language file that has multiple test cases written in a story like manner to describe the feature.

ok lets add a new feature to our project and see how we can make use of it 

after installing specflow, and clicking adding a new item, an item set should appear like the following

As you can see the feature files are listed and multiple languages are supported in feature file types,

since i don't know any Dutch and my french is not that of a proficient level so i will go with English,

and i will name this since my features a login, i will name it ValidateLoginButton.Feature as you see the file extension is Feature and if you expand the file there should be a cs file that contains generated mapping code to the user stories written in the feature file, so lets try to write a test case 

first it is favorable to add a feature description and it goes in the beginning of the document by adding Feature keyword : then a brief description for the feature to be tested 

 Feature: Validating the login button       
  We want to validate the login button  

then we can write our first test case and in this case i will check if the login button is existing in the login page 

and this will go as following 

 @buttob_exist  
  Scenario: Validate Login Button Exists  
   Given I am on the Login screen  
   Then I should see a button named "Login"  

and this example the check checks if user is on the login screen and there is a button login in the page. 

so should i just run this test case and assume that it will work correctly ? the answer is no, because we will need to make these natural language sentences to actual code ?

we can do this using method decorators provided by specflow nuget package, the attribute [Binding] 

which if we decorate on a class it states that this class contains steps that can be linked to test cases statements  and as following we will start with the "Given i am on the login screen" so first we need to map the text using an attribute, since this is a given statement we will used the given attribute as following

 [Given (@"I am on the Login screen")]  
           public void GivenIAmOnTheLoginScreen ()  
           {  

           }  

Note the Given attribute is followed by the same text written in the test case, and that is how the binding works 

and for the "Then I should see a button named "Login"" it should be using the Then Attribute 

  [Then(@"I should see a button named ""(.*)""")]  
     public void ThenIShouldSeeaButtonNamed(string buttonName)  
     {  
       app.WaitForElement(c => c.Marked(buttonName));  
       app.Query(c => c.Marked(buttonName)).Length.ShouldBeGreaterThan(0);  
       app.Screenshot("Then I should see the '" + buttonName + "' task in the list");  
     }  

and likewise we can add attributes that can be passed from the test case in the feature file to the test code  like for instance if we want to check the color of the button so this test case will be like 

 @button_color  
  Scenario: Validate Login Button color is #3b5998  
   Given I am on the Login screen  
   Then I should see a button named "Active Directory"  
   And The button named "Active Directory" should have the color Hex code "#3b5998"  

and the test code for the new state

[Then(@"The button named ""(.*)"" should have the color Hex code ""(.*)""")]  
     public void ThenIShouldSeeAButtonWithTheColor(string buttonName,string colorHex)  
     {  
       app.WaitForElement(c => c.Marked(buttonName));  
       app.Query(c => c.Marked(buttonName)).Length.ShouldBeGreaterThan(0);  
       app.WaitForElement(loginScreen.loginButton);  
       var backgroundColor = app.Query(c =>   
                       c.Button(buttonName).Invoke("getBackground").Invoke("getColor"));  
       Assert.AreEqual(backgroundColor,colorHex);  
       app.Screenshot("Then The button named " + buttonName + " should have the color Hex   
            code "+colorHex);  
     }  

so lets run the tests 

running specflow test or debugging is done through right clicking the feature file itself and choosing weather to debug or run the tests 

and this is how test run looks like, 

To wrap things up, in order to write test efficiently there is a need to have some sort of organization around your code, a commonly used pattern when doing UI BDD Testing is the page object model patter, it is widely used and it is highly recommended, also i do recommend having common binding method to avoid repeating binded tests.

That's all folks.