Creating conversational AWS Lex Bot tests

There exist several ways of testing Amazon AWS Lex Bots, however, either they are manual or require low-level use of the PostContent method. We will introduce here a way of automating part of the process using python.
Read the article at creating-conversational-aws-lex-bot-tests

AndroidViewClient/culebra reached 300,000 downloads

AndroidViewClient/culebra reached 300.000 downloads this month. After some time flying blind, since PyPi statistic stopped working some time ago, this great surprise was awaiting when the counts were restored, now implemented using BigQuery.

Thanks to all who made it possible.

Analyzing Android UI Performance

Integrating UI Performance into your testing practices guarantees interaction with your applications satisfies users’ demands.

Read the step by step guide: https://medium.com/@dtmilano/analyzing-android-ui-performance-52beb577c421

Your first Android Kotlin test

The best part, you don’t have to know Kotlin as the test will be automatically generated for you.

Read the step by step guide: https://medium.com/@dtmilano/your-first-android-kotlin-test-fe007ec41bc5

CulebraTester: Android Kotlin test generation

Recently, Kotlin was made an official language on Android.

It's very easy to get started using Kotlin as it works side by side with Java and C++ on Android.
However, there are new syntax and new language features to learn, even more, when we talk about testing and creating tests for your application UI.
You can gradually introduce Kotlin code to your project as it can coexist with existing code and Android libraries.

So, what's better than start incrementally adding Kotlin to your workflow starting by the tests?
And what is even better is that CulebraTester v0.9.0 introduces Kotlin code generation as can be seen in the previous screenshot.
You can start learning Kotlin now by taking a look at the generated code.

As always, you can find more information about Open Source AndroidViewClient/culebra in its wiki at https://github.com/dtmilano/AndroidViewClient/wiki, about CulebraTester at http://culebra.dtmilano.com/ and https://github.com/dtmilano/CulebraTester-public/wiki and if you have any question you can ask in Stackoverflow using http://stackoverflow.com/questions/tagged/androidviewclient.

Testing Android UI Performance

In a previous post, we were analyzing how to Detect memory leaks on Android apps. That is a very important step in testing and analyzing your application's performance.
Once you are done, you may want to sure that user interactions with your app are smooth, and they run at a consistent 60 frames per second mark.

We will explain here how AndroidViewClient/culebra can help automating and simplifying some steps that usually require manual interaction. In such way, you can measure UI performance, and produce charts that will help you understand and locate the problems 

Latest AndroidViewClient/culebra versions have introduced the ability to plot some metrics from your device or emulator directly. The Dumpsys module obtains and parses dumpsys information to greatly facilitate its usage converting it to objects.

def __plot_dumpsys_gfxinfo(self, pkg):
    self.plot.append(Dumpsys(self.device,        Dumpsys.GFXINFO, pkg, Dumpsys.FRAMESTATS)) \
        .plot(_type=Dumpsys.FRAMESTATS)

This helper method (that can be found in AndroidViewClient/culebra tests) appends to the plot the framestats information obtained from dumpsys gfxinfo for the given package pkg. Then it creates the histogram chart.

This first chart shows the information obtained by running OPEN LIST VIEW from Automated Performance Testing after scrolling the lists.

 This second chart is then obtained by running OPEN RECYCLER VIEW from the same example.

The vertical lines indicate 60 and 30 FPS respectively.

In this case, the improvements made by the RecyclerView are obvious.

As always, you can find more information about AndroidViewClient/culebra in its wiki at https://github.com/dtmilano/AndroidViewClient/wiki, about CulebraTester at http://culebra.dtmilano.com/ and https://github.com/dtmilano/CulebraTester-public/wiki and if you have any question you can ask in Stackoverflow using http://stackoverflow.com/questions/tagged/androidviewclient.

 

Detecting memory leaks on Android apps

More often than it should you find yourself wondering if your application is leaking memory and if so what, where and how.
A lot of questions that usually don't have enough answers.
There are many well know ways your application can leak memory. To name a few

• static references to Contexts, Views or Activities
• inner classes holding a reference to the outer class
• anonymous classes, commonly used in listeners
• drawables holding a reference to the Context
• and many more cases

If you are interested in more detailed descriptions of these common ways your app can leak memory this article will help you.

Also, as there are pitfalls there are tools to help you find them. Again, to name a few

• Android Studio monitors
• dalvik and art GC log messages
• heap dumps
• dumpsys
• etc.

To do an effective use of these tools and uncover memory leaks you should stress your app, running it for a while, or forcing continuous invocations of Activities, perhaps navigation back to the Home screen and launching the Activity again and again. While you can do this manually and the most obvious cases will be detected, it is always more efficient to automate these steps so they can be run before and after to verify that you actually solved the problem.
And what better than AndroidViewClient/culebra to automate these steps as we have discussed so many times in previous articles. Precisely, one of the latest additions is the ability to capture dumpsys information and create plots with it.

This is an example of a method we can define to exercise our Activities including some extra steps like stopping the application to start clean and forcing garbage collection along the way (see complete source code here)

def __plot_dumpsys_meminfo(self, pkg, activity, method=None):
    self.device.shell("am force-stop %s" % pkg)
    for n in range(20):
        if n % 5 == 0:
            self.device.shell(
                "run-as %s pgrep -L 10 %s" % (pkg, pkg))
        self.device.startActivity("%s/%s" % (pkg, activity))
        time.sleep(2)
        if method:
            method()
        self.plot.append(Dumpsys(self.device, Dumpsys.MEMINFO, pkg))
        self.device.press('BACK')
        time.sleep(0.5)
        self.device.press('BACK')
        time.sleep(0.5)
        self.device.press('HOME')
        time.sleep(0.5)
    self.plot.plot()

With every iteration, we are collecting the dumpsys meminfo for the process, exiting the app by sending BACK and returning to Home, and at the end, we plot the chart.

We can easily see that while we are forcing GC the amount of memory used, the number of Activities and Views are constantly increasing.

As always, you can find more information about AndroidViewClient/culebra in its wiki at https://github.com/dtmilano/AndroidViewClient/wiki, about CulebraTester at http://culebra.dtmilano.com/ and https://github.com/dtmilano/CulebraTester-public/wiki and if you have any question you can ask in Stackoverflow using http://stackoverflow.com/questions/tagged/androidviewclient.

Hope this help you spot some leaks in your app.