Displaying 1 to 5 from 5 results

Atmosphere - Black box testing framework for Android

  •    Java

Atmosphere is a simply a black-box testing framework for native android applications. You can configure which tests are going to be executed on which device. You can even specify tests to be run on multiple different, in parameters devices, simultaneously.

appium-parallel-execution - Example of paralled execution using Appium and Selenium Grid

  •    Java

##Appium parallel test execution Here you'll find out how to execute tests in parallel using Appium and TestNG. I have built the apps for Android and iOS platform, and these are located in app folder.

kheera-testrunner-android - BDD Framework for Android

  •    Java

Kheera is a BDD Framework, especially design for Android application development workflows. It's designed to be fast, small and completely compatible with Android Test Kit, Espresso 3, UIAutomator etc. Android Test Support Library: Builds on top of the newest Android Test Support Library and AndroidJUnitRunner. Kheera tests will run alongside existing Instrumentation, Espresso or JUnit based tests in your solution. You can gradually rewrite tests in BDD as you go.


  •    Kotlin

The purpose of the project is to demonstrate the approach of testing the UI in Android app, by using espresso. The project has a very simple login screen, and based on the input it has to show an error, or open the main application screen. The key point of this project is to demonstrate the approach for getting a rock-solid UI tests that would run on any environment, without any external dependencies. Traditionally, there were different approaches for mocking a rest service that would run on the same machine with the emulator, so the app would make the real calls. In this example, the test doubles are created and kept in the source code, so the app would not need any external dependencies for running the UI tests. Furthermore, the replies are very fast so there is no need for any idling resources. The idea is to focus on the UI, because the initial intention is to test the UI, not the actual calls. At the beginning, it's very important to note that the project has 2 flavors: mock and prod. The reason behind is to separate the data source. The production data source implementation would make the real work (calls to sever, etc), while the mock implementation would return mocked replies (aka test-doubles) based on the input. This could have been done in many different ways (using dagger for instance), but the intention here is to achieve the goal with as little dependencies as possible, so it will be very simple to be understood.