Skip to main content

Posts

Showing posts with the label mobile testing

Implementation of Page-Object-Model (POM) to Espresso (Native Android Testing) with Kotlin

What is Espresso Espresso is a native test automation tooling developed by Google for Android UI Tests. Espresso is open-source, very stable, and there are many frameworks that have been developed around Espresso. The  Espresso testing framework , provided by the Android Testing Support Library , provides APIs for writing UI tests to simulate user interactions within a single target app.  It has a full feature-set of Junit that works with Espresso Android Studio provides everything you need It provides white-box testing What Google says about it Page Object Model (POM) The main idea behind the Page Object Model (POM) design pattern, is to create an object repository for the pages in the application, which will then be used in the tests. In other words, instead of including the page elements and the test code together within the test, we separate them into 2 different entities: the pages and the test scenarios. Using this concept, each screen in the application will have a corresp

Implementation of Page-Object-Model (POM) to XCUITest (Native iOS Testing) with Swift

What is XCUITest and XCTest Xcode UI Testing is also known as XCUITest  is a huge expansion of the testing technology in the Apple platform apps like iOS.XCTest is a general testing framework, used for unit integration, network, or performance testing of Apple platform apps. With XCTest you can treat it as a xUnit type of test framework, which can be used for lower-level testing. The XCUITest framework is an extension of the XCTest framework but there are some basic differences between XCTest and XCUITest framework. XCTest framework is a completely white-box framework where you can access the data and API in your main app. XCUITest is completely black-box to your app, so you cannot access the data or API of your main app. Page Object Model (POM) The main idea behind the Page Object Model (POM) design pattern, is to create an object repository for the pages in the application, which will then be used in the tests. In other words, instead of including the p

Testing Mobile Apps in the Cloud - Product Comparison

Cloud testing is raising, especially for mobile automated testing it is even going faster. Basically, cloud testing means that an application is installed on real devices or simulators/emulators that are hosted in one of the cloud testing services providers. These devices are maintained by the service providers and promise to be up and ready for service with a subscribed contract so no need to tackle these kinds of stuff for the sake of focusing on building the right product with well-tested features. In this post, I want to share some info about main mobile cloud solutions in the market.   PRODUCT PRICE SUPPORTED TOOLS AWS Device Farm Pay as you go $0.17 / DEVICE MINUTE Test on any of our devices in parallel and pay just for what you use Your first 1000 minutes are free* Unlimited testing STARTS AT $250.00 / MONTH Test as much as you want each month for a flat

Bitrise integrate Browserstack to Run XCUITest

Bitrise is one of the best solutions for mobile application development. It gives us many mobile app-related steps to create CI/CD (continuous integration / continuous deployment) pipelines (or workflows as in the Bitrise). Around the mobile application development ecosystem, we have many cloud solutions to make quick and reliable development processes. Browserstack is also one of them, it is widely used in web development and testing but also it also has nice features like 'App Live' and 'App Automate' for mobile app testing. In this post, I want to share how we can integrate Browserstack to Bitrise to run XCUITest. Run XCUITest on Browserstack via Bitrise If you want to run XCUITest on a real device then you must build the for generic iOS devices. Building for generic iOS devices requires provisioning so you should ensure that you added the provisioning step to the workflow. Also to be able to run an iOS build on a real device, the device should be registered to the

Bitrise Integrate Browserstack to Run Espresso Tests

Bitrise is one of the best solutions for mobile application development. It gives us many mobile app-related steps to create CI/CD (continuous integration / continuous deployment) pipelines (or workflows as in the Bitrise). Around the mobile application development ecosystem, we have many cloud solutions to make quick and reliable development processes. Browserstack is also one of them, it is widely used in web development and testing but also it also has nice features like 'App Live' and 'App Automate' for mobile app testing. In this post, I want to share how we can integrate Browserstack to Bitrise to run Espresso by directly calling the Browserstack API. Run Espresso on Browserstack via Bitrise If you want to run Espresso tests on a real device then you must build the android project testing so we need to add the ' Android Build for UI Testing ' step then add a script runner to run the Browserstack script. See the workflow: In this example, we are using a scr

Benefits of Using Native Mobile Automation Tooling: Espresso and XCUITest

Testing will be more efficient when testers and developers work in collaboration. Especially when it comes to automated testing, we have many challenging points that should be solved with the help of the other team members. This is a basic explanation of the cross-functional team. For mobile application automated end-to-end testing, this cross-functional team approach can be easily applied by contributing the same code base so native toolings give us this. This can increase the quality of the tests code and the framework by the feedback from the developers, and increase the quality of the tests by the feedback from the testers. In this post, I want to give some idea about the benefits of using native mobile automation toolings such as Espresso and XCUITest. What is Native Tooling Native mobile automation toolings are integrated libraries to the mobile application development framework so that developers can write UI tests for the products under development. Native toolings are part o

Getting the text of elements in Espresso

Espresso is not designed to play with UI objects. When you are considering it in terms of capability for testing, it needs to be improved more. It is not as mature as Android SDK itself so you need to customize somethings to handle your requirements. Even you may need to use other tools like UIAutomator integrated into your test suite. In this post, I want to show how we can handle getting the text of ViewInteraction view.  ViewInteraction view does not have .text function for getting the text of the object since it is designed to interact with the object. Another method which may solve the problem of the assertion is to use the .check for matching the text, as follows: However, this method is not a good way to assert that a certain field text equals a value. For this purpose, we need to get the text of the element and assert it. To get the text of the ViewInteraction element, we need to cast it to TextView with getting the assignable form of it then

How to Set Shared Preferences in Espresso Test for Kotlin and Java

I have experienced Espresso and needed to deep dive into Shared Preferences just because it is one of the main parameters used in the application we developed. As a long search in the online sources but there are some pretty old documents for Espresso with Java and very few documents about Espresso with Kotlin. In this post, I want to share my experiences with setting Shared Preferences with Kotlin and Java and how you can use it in your test design. You can follow up the steps for your test project. Shared Preferences is a way to store user data in local devices so it has been supported since the very early version of Android. Shared Preferences can be stored in the default file or custom file.  Using Default File for Shared Preferences If your application uses the default file it should stores the shared data in the default file provide by Android as in the following path in the device: /data/data/com.package.name/shared_prefs/com.package.name_preferences.xml This

First Checks for Mobile Application Testing

Mobile application testing world is differentiated from web application testing in terms of the power of the control. The definition control , how much things you can do when users install the application to their mobile devices. Think, if you store warnings in code and deliver them inside the application code, you can not manage it unless the users update the application. For sustainable mobile application development, you should have the control of the applications as much as you can do. Therefore the architectural design of the application should be ready for this flexibility. In this post I want to share the most important and primary checks for mobile application testing. Security First Whatever you develop, you can not disregard the security of the users. If you have an open deep-link for critical information, it will one day be distinguished by some one. Critical actions, such as login, sign-up, credit card submit, should not be sent over get requests , they

Mobile Test Automation: Appium with Python Client

Appium is an open source tool for mobile test automation, you can automate functional test cases for Android and iOS application. As in my some previous posts, I explained Calabash and I just used Ruby for writing test cases because Calabash only supports Ruby and as I know they have plan to support Java. However Appium doesn't have this language constriction. Since it uses Webdriver, it supports the languages which are supported by Webdriver. It means that Java, Objective-C, PHP, Python, C#, Clojure, Perl, JavaScript with Node.js and plus Ruby are supported. You just install the language client you want to test and then write your test cases. Check for the client for your favourite languages from Appium page . Install Appium: npm install -g appium Install Appium Client: npm install wd Install Python Appium Client: pip install Appium-Python-Client Ensure that you have Python installed, recommend to have 2.7 or above: python --version Ensure that you have

Mobile Test Automation: Calabash, Cucumber

Mobile test automation is just another era for test automation since the trends for mobile devices are increasing. For more sophisticated testing approach, we should apply the technics what we have learnt from the test automation for desktop/web applications. As test automation is a part of continuos development, it should be run after each commit to test environment. For mobile application we can use the same method to be more responsible.  Cucumber is used describe the test cases and it very easy to understand for anyone so we can use it for user behaviour as behaviour driven development, BDD . Capybara is a library to simulate user behaviour for just web application. However we can use Calabash for mobile test automation.  It means that we can use Calabash and Cucumber together for mobile test automations. As in Capybara, in Calabash there are not much functions to learn. It has basically, finding element, inserting text into textEdit fields, clicking and assertion function