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();
}


Sunday, February 26, 2012

JInjector - J2ME Instrumentation testing


JInjector is an Instrumentation tool for Java Mobile Applications. 

J2ME applications consist of having a pair of files: the JAR and JAD. JAR file containing all the code and resources and JAD file is a text based containing execution parameters. The Deployment is J2ME applications as these tend to include code optimization and obfuscation, together with signing also.

Here the JInjector applies the Instrumentation and resulting classes are pre-verified and packaged together a specific device. But the Initial jar file should not obfuscated (or) optimized. The whole process and the testable code must be preverified again and The JAD descriptor file needs updating with the new JAR size. It instruments the system under test (SUT) in order to run automated tests in emulators and on the actual devices and It can also supports for code coverage.

Below the sample screenshot for the overall architecture



How to instrument LCDUI
LCDUI has strong has encapsulation and those classes cannot be instrumented. Because they are not part of the JDK. For Java Reflection They have done Java byte code conversion - a general purpose instrumentation tool based ASM

The Java ME code:
                        Form form=new Form();
                        form.addCommand(command1);
            Will be instrumented as
                        Form form=new FormWrapper()
                        Form.addCommand(Command1);

Here some of wrapper classes below
Alert- Alert wrapper, Canvas-Canvas Wrapper, Form – Form Wrapper, .. etc

And Wrapper classes have methods like as ……
getTitle();  getCommand(); getAllCommands(); commandListner(); .. etc

Simple test case using wrapper class methods
FormWrapper myForm = (FormWrapper) myScreen;
  assertEquals("The form title should be Sign in","Signin“,myForm.getTitle());
  Command c[]=myForm.getAllCommands();

A Test Method
Package com.reddyapp.test.auth.register;
import com.reddyapp.j2me.JInTestCase;
public class TestHelloMIDlet extends J2meTestCase {
                        public void testRegisterForm (){
                        }
}

Test case Asserts
public void testRegisterForm (){
assertEquals("The form title should be Reddy, “Reddy“, mainForm.getTitle());
}

Test Reporting and Test Results



Sunday, February 12, 2012

Test your mobile web application with MITE (Mobile Internet Testing Environment)

I hope this post can help you to how to present and test your web application accessing through into different devices.

Now a day’s People are spending more time on mobile devices and Tablet P.Cs than to traditional computers. Web Sites must be providing an excellent experience to visitors using one of many thousands of mobile devices. We may expect traffic in the thousands of users every day.

So Development and QA team has to take care of their web pages to present, test and verify that content is correctly formatted & displaying across mobile devices. In these areas you need to be test each and every screen with HTML elements (attributes, content, Styles), Local storage (Offline storage & online storage), cookies and application cache.

Here is some of the useful information about How to launch and view the web page content


Launch the GoMO

Take the URL of your Test web page and paste it in there. You can see your desktop site on a mobile phone. It can help you to improve the customer or User web view experience

The mobile Web view results will be displayed as per below


MITE comes with a script recorder that lets you capture each step as you navigate a mobile website and also you can be able to test many devices at time

Here are some open source tools for I Phone Browser test and debugging for your I phone web application

I Phone Browser testing:  iwebinspector

Cross verify your mobile web features with below link
HTML5 compatibility on mobile and tablet browsers: Web features Cross verification


Friday, November 25, 2011

Droid Explorer - Android Stuff into One place


Droid Explorer is a open source & completely free app for your Desktop computer.
It can help you to get the screenshot, video recording logs & system files from your android rooted phone. But it needs the android SDK installed in your computer.

Please find the followed link for to get this app

Wednesday, September 21, 2011

Android testing with Maven build management


This post may be can help you to quick start for android testing as with maven


As we know Maven can build the android projects + runs the Instrumentation tests. Like Building, Deploying, Testing and Advanced level reporting.. And also having a very good folder structure to keep all the source test classes and run into the several devices

Using by maven you easily maintain extensive unit tests and your activity tests, service tests, content providers tests and all in to one place...


A sample Maven Android Test Directory 


..app> mvn install

When you run this target, Firstly it can compile the all the source class files Secondly, it  can run only the unit test cases  and generate the reports.

..app-Instrumentation> mvn install
This target compiles the automation test cases and generates the test .apk file

Robotium using by Maven  
You can also write automation UI test cases by using Robotium for automation testing. There is no need to attach Robotium jar file. This jar file will take from repositories itself. All the dependencies will automatically download. You can also execute same test suite in to the number of devices also.

Advantages :
1. Run the test cases by using single command from the command prompt
2. Multiple device support for test execution
3. Automatically generate the test reports in the XML format for each and every device which are connected
4. No need to worry about signature(signing) 

Dis Advantages:
1. The build system can depend on the source code. So without application source code it is not possible to run your automation test cases... 

For use to get robotium in your test project , You need to add the followed dependency  


Test Suite building

import android.test.suitebuilder.TestSuiteBuilder;
import junit.framework.Test;
import junit.framework.TestSuite;
public class AllTests extends TestSuite {
    public static Test suite() {
        return new TestSuiteBuilder(AllTests.class) .includeAllPackagesUnderHere() .build();
      }}

Running tests

If you use a test runner other than InstrumentationTestRunner, you must change the element to point to the class you want to use.

instrumentation android:name="android.test.InstrumentationTestRunner"
                       android:targetPackage="com.pkg_name "

Once the Instrumentation starts, android system classes can load and start the test package, If any other processes are running it can kill all the processes and run an instance of the application under test, and then it can load a new instance of the application under test.

…app-Instrumentation> mvn android:deploy 
This target can run the Instrumentation can start and can run with the device or emulator 

Multiple device support for deploying and getting the test results for Test reporting 

If you run a test in Eclipse with ADT, the results are displayed in a new JUnit view pane only and again at end of the test, you have to export the results in to the XML files…

So it is very hard to run and saving the reports. and also time consuming

In this case maven can the run unit tests and instrumentation tests in the number of devices and finally it can generate the reports into the XML files and save the reports for each device or emulator


A sample automation report generated by Maven run time environment



In this case I have attached one real LG Android device, 2 emulators and the XML file reports has generated with prefix name as a “TEST-……..”

You can also give the name of the devices to only run all emulators or only all devices or only a specific device
mvn android:deploy -Dandroid.device=emulator-5554
mvn android:deploy -Dandroid.device=emulator-5556
mvn android:deploy -Dandroid.device=someAvdName
mvn android:deploy -Dandroid.device=8283838993839393AESA
mvn android:deploy -Dandroid.device=deviceSerialNumber 


Followed links may be help you to get know more details about this