Wednesday, August 5, 2015

ATBP - Android Testing Blue Print is now available !!!


Great collection of testing technique using the full spectrum of tools available to Android Testers. This repository will make it easy to get you started with test integration in existing and new projects. Android Testing Blue Print is available now on the android-testing-templates repository https://goo.gl/eSd8wC on Github. After cloning the repository please make sure you look at the “Getting Started Guide” first to get a glimpse of the project structure and how to run tests for each module.


https://github.com/googlesamples/android-testing-templates?linkId=16056862

Saturday, May 2, 2015

Espresso is faster than robotium

Espresso and Robotium are instrumentation-based frameworks, meaning they use Android Instrumentation to inspect and interact with Activities under test. The major advances in Espresso over Robotium:    

1.Synchronization: By default, instrumentation test logic runs on a different (instrumentation) thread than UI operations (processed on the UI thread). Without synchronization of test operations with UI updates, the tests will be prone to flakiness - i.e. will fail randomly because of timing issues. Espresso takes care of thread safety by seamlessly synchronizing test actions and assertions with the UI of the application under test. Robotium attempts to address this with sleep/retry mechanisms, which are not only unreliable, but also cause tests to run slower than necessary.

2.API: Espresso has a small, well-defined and predictable API, which is open to customization. 

3.Clear failure information: Espresso strives to provide rich debugging information when a failure happens. Further, you can customize the way failures are handled by Espresso with your own failure handler. 

For more information Read More

Monday, April 27, 2015

Android new testing library update

Android new testing library update

                      
          The new Android Testing Support Library provides an extensive framework for testing Android apps with espresso and Android Junit Runner with Android Studio. Now you can be able to run test cases from Android Studio with all connected devices. This library provides a set of APIs that allow you to quickly build and run test code for your apps, including JUnit 4 and functional user interface (UI) tests. You can run tests created using these APIs from the Android Studio IDE or from the command line. There are 3 major updates 1) Android Junit Runner. 2) Espresso. 3) Uiautomator 2.0


Android Junit Runner: 

         The Android Junit Runner class is a JUnit test runner that lets you run JUnit 3 or JUnit 4-style test classes on Android devices, including those using the Espresso and UI Automator testing frameworks. The test runner handles loading your test package and the app under test to a device, running your tests, and reporting test results. This class replaces the Instrumentation Test Runner class, which only supports JUnit 3 tests.

Uiautomator 2.0:

        The UI Automator testing framework provides a set of APIs to build UI tests that perform interactions on user apps and system apps. The UI Automator APIs allows you to perform operations such as opening the Settings menu or the app launcher in a test device. The UI Automator testing framework is well-suited for writing black box-style automated tests, where the test code does not rely on internal implementation details of the target app.

 Espresso:


                      
          The Espresso testing  framework provides a set of APIs to build UI tests to test user flows within an app. These APIs let you write automated UI tests that are concise and that run reliably. Espresso is well-suited for writing white box-style automated tests, where the test code utilizes implementation code details from the app under test. 


For more information Read More

Saturday, December 13, 2014

iOS-Deploy - Install and debug iPhone apps from the command line, without using Xcode

Install and debug iOS apps without using Xcode. iOS-Deploy is will work on un-jailbroken devices. ios-deploy installation is made simple by using the node.js package manager. If you use Homebrew, install node.js: brew install node. You can install ios-deploy with the node.js package manager: npm install -g ios-deploy

Examples:
// deploy and debug your app to a connected device
ios-deploy --debug --bundle my.app

// deploy and launch your app to a connected device, but quit the debugger after
ios-deploy --justlaunch --debug --bundle my.app

// deploy and launch your app to a connected device, quit when app crashes or exits
ios-deploy --noninteractive --debug --bundle my.app

// Upload a file to your app's Documents folder
ios-deploy --bundle_id 'bundle.id' --upload test.txt --to Documents/test.txt

// Download your app's Documents, Library and tmp folders
ios-deploy --bundle_id 'bundle.id' --download --to MyDestinationFolder

// List the contents of your app's Documents, Library and tmp folders
ios-deploy --bundle_id 'bundle.id' --list

// deploy and debug your app to a connected device, uninstall the app first
ios-deploy --uninstall --debug --bundle my.app

// check whether an app by bundle id exists on the device (check return code `echo $?`)
ios-deploy --exists --bundle_id com.apple.mobilemail

// Download the Documents directory of the app *only*
ios-deploy --download=/Documents -bundle_id my.app.id --to ./my_download_location

// List ids and names of connected devices
ios-deploy -c

// Uninstall an app
ios-deploy --uninstall_only --bundle_id my.bundle.id

// list all bundle ids of all apps on your device
ios-deploy --list_bundle_id
For More Information  Read More

Monday, November 25, 2013

iOS App Stress testing


Existing android monkey test technique

Android monkey test tool is a just pseudo – random monkey testing tool. It is not android GUI verification tool. It looks for only crashes and ANR by stressing your android application. Re running the same test against with the same configuration will often reproduce the crashes. If you can run the same test configuration on multiple devices (Sony, Samsung, etc..) and different SDKs (4.3, 4.2, 4, 1, 4.0, 3.1, 3.2, etc...), you can be able to catch bugs earlier in the development cycle of a new release.

Android monkey test can execute the below events and below constraints

Events
Touch
Track ball events
Navigation (up/down/left/right)
Sys keys (Home, Back, Start Call, End Call, or Volume controls)
Constraints
Package (-p) - App package name that you need to test ex: com.example.myapp
Category (-c) -  Visit only specific activities that are listed with one of the specified categories


A sample monkey test report out put
Events injected: 1000000
: Dropped: keys=242 pointers=2342 trackballs=234 flips=423
## Network stats: elapsed time=100914ms (0ms mobile, 0ms wifi, 914ms not connected)
// Monkey finished

The same android monkey strategy can possible to apply for iOS applications. iOS Uiautomation instrumentation tool is offering APIs  for pound on our app with a barrage of taps, swipes, device rotations, and even locking and unlocking the home screen. It supports running automated tests in Instruments using JavaScript.
                The same android monkey technique is possible to apply for iOS apps by customizing Uiautomation java script libraries.

A sample Java script test configuration 

config: {
  numberOfEvents: 1000,delayBetweenEvents: 0.05,// In seconds
  eventWeights: {tap: 30,drag: 1,flick: 1,orientation: 1,clickVolumeUp: 1,clickVolumeDown: 1,
    lock: 1,pinchClose: 10,pinchOpen: 10,shake: 1},
 touchProbability: { multipleTaps: 0.05,multipleTouches: 0.05,longPress: 0.05 }},


Ui- Auto-Monkey
Download the dependent java script libraries from: https://github.com/jonathanpenn/ui-auto-monkey/wiki

Installation
There's nothing special to install since this leverages UI Automation and Instruments that come with Apple's developer tools. If you have Xcode, you've got all you need to stress test your applications with UI AutoMonkey. Follow the instructions below to set up a UI Automation Instruments template with the UIAutoMonkey.js script.
First, load up your app in Xcode. Choose "Profile" from the "Product" menu (or press Command-I) to build your application and launch the Instruments template picker.



Next, you'll want to pick the "UI Automation" template. You can add in other instruments to measure the app's performance under the test after we set up the basic automation template.
Switch to the script pane by choosing "Script" from the dropdown menu in the middle dividing bar of the Instruments document.


Create a script in this Instruments document by choosing "Create..." from the "Add" button on the left sidebar.



Paste in the UIAutoMonkey.js script.  At this point you can simply click the playback button at the bottom of the Instruments window to start the script.


Once you've set up UI AutoMonkey in your Instruments document, you can create a custom template tied to this application that you can double click to run. First, make sure the Instruments document is stopped by clicking the red record button in the upper left of the Instruments document. Then choose "Save As Template..." from the "File" menu and choose where to put the file. Now, you can double click this template to open Instruments with the UI AutoMonkey script already embedded. Just click the red record button in the upper left of the Instruments document and the app will launch and run.

Still we need to customize and improve for our needs Ex: Reporting at end of the test that should say crash where in app, what - time, on what event, total time..etc. 

Sunday, October 27, 2013

Android custom view testing and ensure accessibility services is enabled for all custom view ui controls

Generally, Android application developers get accessibility support for free, courtesy of the view and view group classes.

But however, some applications use custom view components to provide a richer user experience. Such custom components won't get the accessibility support that is provided by the standard Android UI components. If tester wants to perform an action on these custom view components, it’s very hard to create an object reference from instrumentation to click, drag or any other actions. Programmatically traversing of custom view classes is not possible. Here instrumentation is very limited until unless developers can provide the methods to perform an action like on click, touch and other stuff.

If this applies to your application, ensure that the application developer exposes the custom drawn UI components to Android accessibility services. Set an each element’s accessibility status and provide custom content for the label for test automation purpose.

Have a look at this video for accessibility service How importance for end mobile users




Saturday, November 24, 2012

Android uiautomater sample test case with assert verification

I have spent a couple days testing out the new UiAutomator API and thinking that it is like a bridge between android instrumentation and monkeyrunner. By using this APIs, you can develop test case with minimum knowledge and less effort. You don’t need to do any pre-setup like package boundaries and configuring manifest file permissions. 

While designing a test case using Robotium, You must need to include some critical steps like extending from ActivityInstrumentationTestCase2 and passing in the name of the target class creating the constructor that takes no arguments.

But here you don’t need to do anything. You can just create a normal Java project with default folder structure and build the test.jar file with project dependency UIAutomater.jar file

Here as the sample UIAutomater Sample Test case.

public void testDemo() throws UiObjectNotFoundException {

// Press home button.... Don’t care about where your device status or previous test case where you opened.
        getUiDevice().pressHome();

 // open the All Apps view
        UiObject allAppsButton = new UiObject(LauncherHelper.ALL_APPS_BUTTON);
        allAppsButton.click();

// clicking the APPS tab
        UiSelector appsTabSelector =
                new UiSelector().className(android.widget.TabWidget.class.getName())
                        .childSelector(new UiSelector().text("Apps"));
        UiObject appsTab = new UiObject(appsTabSelector);
        appsTab.click();

// Clicking the Settings
        UiScrollable allAppsScreen = new UiScrollable(LauncherHelper.LAUNCHER_CONTAINER);
        allAppsScreen.setAsHorizontalList();
        UiObject clockApp =
                allAppsScreen.getChildByText(LauncherHelper.LAUNCHER_ITEM, "Clock");
        clockApp.click();

// Set an alarm to go off in about 2 minutes
        setAlarm(2);

// wait for the alarm alert dialog
        UiObject alarmAlert =
                new UiObject(new UiSelector().packageName("com.google.android.deskclock")
                        .className(TextView.class.getName()).text("Alarm"));
        assertTrue("Timeout while waiting for alarm to go off",
                alarmAlert.waitForExists(2 * 60 * 1000));
        clickByText("Dismiss");
}

private void setAlarm(int minutesFromNow) throws UiObjectNotFoundException {
        UiObject setAlarm = new UiObject(new UiSelector().textStartsWith("Alarm set"));

        if (!setAlarm.exists())
            setAlarm = new UiObject(new UiSelector().textStartsWith("Set alarm"));
        setAlarm.click();
        clickByDescription("Add alarm");
        clickByText("Time");

        UiSelector minuteAreaSelector = new UiSelector().className(
                android.widget.NumberPicker.class.getName()).instance(1);
        UiSelector minuteIncreaseButtonSelector = minuteAreaSelector.childSelector(
                new UiSelector().className(android.widget.Button.class.getName()).instance(1));

        for (int x = 0; x < minutesFromNow; x++)
            new UiObject(minuteIncreaseButtonSelector).click();

        clickByText("Done");
        UiObject doneButton = new UiObject(new UiSelector().text("Done"));
        UiObject okButton = new UiObject(new UiSelector().text("OK"));

        if (doneButton.exists()) {
            doneButton.click();
        } else {
            okButton.click(); // let it fail if neither exists
        }
        clickByText("Done");
        getUiDevice().pressHome();
}

private void clickByDescription(String text) throws UiObjectNotFoundException {
        UiObject obj = new UiObject(new UiSelector().description(text));
        obj.clickAndWaitForNewWindow();
}

private void clickByText(String text) throws UiObjectNotFoundException {
        UiObject obj = new UiObject(new UiSelector().text(text));
        obj.clickAndWaitForNewWindow();
}

Monday, November 19, 2012

Time to kick off android Instrumentation and monkeyrunner API


Recently I have updated Android SDK Tools 21.0 and came to know that they have added New UI Automation tool for App testers. This is was really cool and kick it off existing like android JUnit test case, monkeyrunner and Robotium APIs as well. This little baby code making more easy to write the test cases with less efforts. I am surely this APIs can be more matured over the next two years.

It is similar to robotium tool but having powerful APIs which it can wakup the device, crossing the package boundaries, rotating  and lock the screen orientation, taking screenshots.

As a test automation engineer, I was really interested on this. Google developers are making their OS more testable so I had high hopes with every release to see in this area. I just read the documentation and observed below good things and bad things

UI Automater

è  Good things
1.     Works across the Android OS System (NOT like package boundaries)
2.     NO connection for you app project (Does NOT require source code)
3.     JUnit based (familiar tool and test case structure)
4.     XML hierarchy dump tool in Monitor like DDMS/Hierarchy Viewer (Identifying the specific UI elements your test will need without the distractions)
5.     Useful and end up being maintained long-term (closely tied to the platform)
6.     Generates a JAR file which you can push in to the device or emulator
7.     Simple, readable, repeatable syntax and Able to crate the OR (Object repository like Q.T.P or Selenium)
8.     Updates and Bug fixes seem likely to be released infrequently

è  Bad things
1.     Still NO eclipse integration
2.     Still NO Native JUnit XML Reports
3.     Cannot be Downgraded (Only 4.1 or higher versions)
4.   WebViews still NOT supporting

Monday, July 23, 2012

Verify Android Device screen resolutions as with your Application Tests


This post can help you to verify the height and width of  Android Device Screen resolutions along with your application tests

public void testScreenResolution(){           
Context mContext = getInstrumentation().getContext().getApplicationContext();
// Here the Height of Screen expected value is 480
assertEquals(480,getScreenHeight(mContext));
// Here the Width of Screen expected value is 320
assertEquals(320,getScreenWidth(mContext));         
}

public static int getScreenWidth(Context context){
WindowManager windowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
Display display = windowManager.getDefaultDisplay();
return display.getWidth();
      }
   
public static int getScreenHeight(Context context){
WindowManager windowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
Display display = windowManager.getDefaultDisplay();
return display.getHeight();
}