Skip to main content

Posts

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

Centralized Monitoring System for Automated Tests with Elasticsearch and Kibana

In this post, I want to give you some practical information about a monitoring system for automated tests. I will touch the following topics: Why we need a monitoring system for automated tests What are the potential benefits of the monitoring system A simple approach using the following technologies: Elasticsearch Kibana Firebase test lab, gcloud and gsutil XCTest and Espresso What is the Centralization of Log Systems In a development pipeline, we have a variety of tools and technologies with different languages and scripts. CI/CD pipeline is a good place the see the process of the development, but to get the detail of an item in the pipeline, we need to get into that item and tackle with logs and data. Some times this investigation requires some capabilities to understand it. One of the easiest ways to get a common understanding from the logs in the pipeline is using one easy tool for the whole process. When we collect all the

(Framework) API Test automation with Ruby Rspec and Airborne

Automated tests for API and services are very important so there are lots of solutions for API test automation in the market. These solutions can be commercial-off-the-shelf (COT) or opensource libraries also, there are many frameworks created around these opensource libraries. Testing APIs with tools that have IDE can be easy to start and learn but it can be challenging to customize for your unique problems or integration to CI/CD tools can be hard. Therefore I can suggest you use one of the opensource libraries by implementing it with your favorite language. In this way, it can run faster,  easily extendable, and configurable.  I have created a framework with Airborne and Rspec for automating API tests, you can  check it from Github .  In this post, I want to explain what is Airborne and how I implemented a framework around it. You can simply update the environment variables and write your specs file in the ` specs ` folder.  What is API Testing API stan