Skip to main content

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 

  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 

  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);  
       var backgroundColor = app.Query(c =>   
       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.


Popular posts from this blog

(AsyncWebClient) Async Webclient for windows phone 8

Using windows phone web client is pretty common but the thing is you can not use it using Async -> Await mechanism so i used threading to create an async functionality for The Download string and upload string methods here is the code below // Comment public class AsyncWebClient { public Task DownloadString(Uri uri) { var task = new TaskCompletionSource(); try { var client = new WebClient(); client.DownloadStringCompleted += (s, e) => { task.SetResult(e.Result); }; client.DownloadStringAsync(uri); } catch (Exception ex) { task.SetException(ex); } return task.Task; } public Task UploadString(Uri uri, string content) { var task = new TaskCompletionSource(); try { var client…

RuntimeBinderException cannot resolver property in Unit Test in case of dynamic return.. Solved

Xamarin UI Tests – Deep dive Part 1

IntroAs the title may describe this is the first of the series of articles that will cover the UI Test of Xamarin in a deep dive, we will start simple and then dig deeper as we go. Since this is very well the first of the series, it will mostly cover up the architecture and the testing technique that Xamarin UI Tests uses.

The Technology
Xamarin UI Test is an automation testing framework similar to selenium, Watir, Watin (.net), Robot and Sikuli, if you have used BDD (Behavioral Driven Development) or a more advanced TDD (Test Driven Development) approach at least you must have come across one of these frameworks, and in that perspective comes Xamarin UI Testing as an automation framework designed specifically for Xamarin Automation testing, For starter Xamarin UI Tests was not build from scratch, instead it was built on top of another UI Automation testing framework that is targeting android and iOS sepecifically which is Calabash, I have to say that this choice was made wisely as of n…