VALIDATE SMART!
Simply pressing ‘validate’ is not enough. It never was and it never will be! Testing sessions are held in order to validate whether the app is acting as it is supposed to. Every tester at a certain point of his career realizes he actually sucks at testing. Sure you may take the device with the app installed, swing it around, tap every button and call it a day and hit validate. But will such an approach work for the end-users? Will they get a product of highest quality? Unlikely.
But it’s never late to begin with advancing your skills as a tester. Automating UI is a great way of getting accustomed with both scripting and automation in general. Plus such an approach will bring profit to all the projects you are working in.
LET’S BEGIN WITH GHERKIN
What’s UI automation? The process of making the machine tapping all the buttons you would by personally if speaking in general. You will be using the Gherkin language to do so. The language will convert you language into testing phases you wish to automate.
How’s it working? Well, here is a fine example of Gherkin in use:
Feature: Some words you will use to describe what is the actual value desired by business requirements for This particular feature and, of course, there will be some extra info about the parts that will make the actual feature quite easier to understand.
Scenario: Creating a new document
Given a brand new document
When I touch ‘create new doc’ button
Then I should be asked ‘what will be the name of your new document’
And any other possible action
And one more
Then there has to be a predictable result
That is an example of how Gherkin is working for you. Does not seem too hard, is it? But what was all that blah-blah about and what does it have to do with coding?
- The first few words were starting the feature followed by some descriptive text, supposed to describe the actual business value of the feature
- Then the scenario was started
- The lines afterwards were the steps the scenario should follow
This is an actual real (I am not making things up) scripting language. Some are finding it a bit awkward (the nicest fitting word I’ve came up with) but hey, it works and is doing what it’s supposed to. the steps are centered around one scenario. All of them are either marked with
- Given (is setting up the test’s preconditions)
- When (is specifying an action taken or the any other event)
- Then (is validating the app’s state)
or
- And
- Or
- But
are used to make steps more readable. These labels have no actual meaning and will be ignored during the test process, thus they are simple assistants of readability.
Such scripts may be used in many ways by the way hence they are written in readable English. They may be used as actual documentation hence they are pretty much explaining what a feature has to be capable of and what it is expected to do.
CAN SUCH SCRIPTS GO DEEPER?
Do you know what will happen if these scenarios will be written before the actual app’s code itself? You will be into a process looking like TDD. But regarding on the higher usage level we are actually talking about BDD. How is the BDD process going?
- You are imagining a potential feature
- You are documenting it as a pack of users scenarios (like in the example above)
- Then you code until the code passes steps 1 and 2
That is where you will require assistance of the Cucumber tool for executing your scenarios (as all of testing cant flow in imagination only). Cucumber is designed to handle such exact workflow thus it is by default the perfect thing to use.
CALABASH
If you are into mobile application testing calabash is what you are looking for hence it is cross-platform (meaning it is supporting both Android and iOS apps) and will allow you to write and execute automated acceptance tests for your mobile application. The closest thing is the Selenium WebDriver. But you are to realize that interacting and testing a mobile app from a desktop computer is a totally different experience from what you may experience using a touchscreen.
The Calabash choice is predetermined hence its APIs, specialized on touchscreen device running apps. Calabash will be doing the testing and it’s calls will be done via Gherkin DLS Step Definition files.
SEEING YOUR APP FROM A DIFFERENT PERSPECTIVE
Note: To be more readable and understandable the next part will have examples of an iOS app under test. The process with Android apps is not very different, yet speaking of a particular example has more educational value than just few general words.
Once Calabash is installed you are granted access to a tool named calabash – ios console that will grant you with an accessible Calabash API while an interactive Ruby session is commencing. All that needs to be done is running your app in an iOS simulator. Launch the console and you are ready to go. Go where? Exploring, of course.
You are free of typing in queries as query(“view”) that will allow you to see all the views that are visible. This query will allow you with:
- A list of visible views
- Those view’s classes
- Their screen position
- Accessibility labels
The first step was made and all that is left is an interesting journey around your application in order of discovering what is hidden beneath the fancy looks. Discover which exact queries are identifying the views you were looking for.
Exploring may be quite fascinating, yet it tend to take way too long. You may use a short-cut query named lables. All it does is actually labeling things, thus after typing labels(“button”) you will see a list of UI buttons that are visible on your screen.
WHAT TO ACTUALLY DO?
- First thing’s first. Install calabash as well as Cucumber. You are to use gem package by Ruby to do so.
- Calabash will be using an internal server for interacting with your app thus make sure it’s set up fine.
- Create some cucumber features. Invoking a command $ calabash – ios gen inside your iOS directory will create a sub-directory for your features.
- Write features like the ones in the beginning of this post.
- Cucumber will run your features as well as their scenarios.
- Sett the environment variables if necessary before executing Cucumber with a line like:
$ SDK_VERSION=7.0 DEVICE=iphone cucumber - Any specific features may be run by you as well, as arguments to Cucumber itself
$ cucumber features/rename.feature
Enjoy a well-tested app!
No comments:
Post a Comment