My First (and the) First Appium Conference

Last year, I was selected for a scholarship to Appium Conference 2018 by White October Events. I’ve been aware of Appium for years now as I’m an app developer but I’ve not (yet) used this tool on any of my projects.

For those that don’t know, Appium is a mobile testing framework built upon the Webdriver technology. It was created in 2013 by Dan Cuellar. He was an Test Manager at Zoosk who  was finding that the length of the test passes on the iOS product was getting out of hand. Appium allowed him to write automated tests for iOS as easily as Webdriver was used for automating websites.

Five years later, Appium has a massive community building up a successful open source project that can be used on Android, iOS, Windows in a variety of coding languages.

This year was the first Appium Conference.

There was only one track which was great because I got to see everything and didn’t have to pick between two talks that were probably going to be beneficial to me.

Interesting Things to Note

  • There was a lot of variety of languages being used with Appium (part of the appeal of using the product I suspect).
  • Lots of people were using Jenkins with it as their continuous integration/continuous delivery tool. There were a couple mentions of Circle CI but none about TeamCity. Because of this, I think I’ll be looking into Jenkins more than TeamCity for my app projects.

All the talks were highly interesting and not too difficult to follow for a beginner like me. So I want to share my biggest takeaways from each of the talks.

Keynote – Appium: The Untold Story

The day began with a keynote from Dan Cuellar and Jason Huggins. They spoke about the history of Appium, where it is now and briefly touched upon where he wants it to be in the future and mentioned their vision of StarDriver.

They want to see Appium grow it’s users and the platforms it can test particularly to the internet-of-things and various hardware.

The best takeaway for me from this keynote was the phrase “Challenge everything you see”.

Appium: A Better way to Play the Game

This first talk was given by Charlene Granadosin & Charlotte Bersamin. What I found interesting within their talk was how they were integrating their release and exit reports within Jira using Xray. They used a curl command to upload their latest test results to Jira so these results are clearly visible to the Product Owners or Managers of the team.

My biggest takeaway from this talk was to investigate whether the tools we were currently using for test case management was able to integrate with Jira to give such detailed reports and to try and get the automation up and running.

Deep Hacking Appium for Fun and Profit

Daniel Puterman‘s talk explained how he had contributed to the Appium project by creating a new endpoint to gather native application screenshots.

Because the company Daniel worked with was Applitools, my biggest takeway from this was to figure out whether visual testing tools would be useful for testing virtual reality (VR) applications as much as they would be for websites of mobile applications.

Why the h# should I use Appium with ReactNative?

Wim Selles delved into a comparison talk about why they chose Appium (which was extremely useful as I’ve also been debating what automation tool to use for mobile apps).

Out of all the frameworks he mentioned, they went with Appium because it fit with a lot of his requirements for testing ReactNative apps.

There were a lot of takeways for me from this talk.

  • Consider your own project requirements when you pick your automation tools
  • What are your requirements?
  • What should your app do (now/future)?
  • Which tool supports your needs/expectations?
  • Do a proof of concept test
  • Do research into competitive tools

He also gave a couple of good ways that you can speed up app testing:

  • Remove animations on screens
  • Utilise deep-linking to get directly to screens

Layout Automation Testing (GUI)

Prachi Nagpal explained how she was using Galen to perform her UI browser based testing for mobile and desktop devices. Galen does this by measuring the distance between elements that are being tested. You can also produce heatmap results from this tool.

It was a good talk and interesting to see a tool that I had never heard about.

Can you please provide the full Appium Server logs? A Brief Tour of the Logs

Isaac Murchie next walked us through the Appium logs and the takeaway here was that he pointed out that some lines are bolded to highlight their importance.

He also noted that the following are ways to know which are requests and responses in the logs.

This is a request:

[HTTP] -> 

This is a response:

[HTTP] <-

Interaction with Native Components in Real Devices

In his talk, Telmo Cardoso told us how he tested native components of mobile operating systems. He explained the challenges that he faced (some tasks were difficult on one platform but easier on the other) and ways he and his team had got around them.

The areas he found challenging were:

  • Adding contacts
  • Pushing files to a device
  • Push notifications
  • Managing calls
  • Simulating low battery
  • Extracting logs

The biggest takeaway from this talk was that he used Cucumber for his automation framework along with with Appium successfully to test the native applications and features of smartphones and not just the applications running on them.

Using Appium for Unity Games and Apps

Because of my daily work with Unity projects, I was particularly looking forward to Ru Cindrea‘s talk on how she used Appium for her Unity games and apps.

She first explained how she used OpenCV an image recognition tool with Appium to try and test her Unity games.

The positives were:

  • Works for simple scenarios
  • No changes to game required
  • Found issues like performance issues or out of memory crashes

The negatives were:

  • Wasn’t fast enough
  • Not for games with lots of text

So she decided to create a component called AltUnityTester to help her with her issues.

AltUnityTester is created with Python bindings. It opens a socket connection and waits for a response on a specific port.

When the AltDriver is added into the Appium project it gets a list and knows everything about that Unity scene’s objects. It can then send a command to that port to get information back from the scene to perform tests e.g. checking the end position of elements or text output.

This solution is useful because it’s real-time but it does require changes to the project and it only works with Unity.

So my biggest takeaway was to investigate whether this AltUnityTester could be extended or something similar made in order to test VR applications using Unity.

It’s available as a Unity package or on Gitlab.

Docker-Android: Open-source UI Test Infrastructure for Mobile Website and Android

Application

Budi Utomo next talked about his Docker-Android image to test Android projects and websites on Android devices.

His plan for project development was to:

  1. Create UI tests for Android devices
  2. Write unit tests on Android
  3. Create UI tests on Android apps
  4. Implement Monkey/Stress tests

The biggest takeaway was the demo that showed how Appium can be used easily within Docker containers.

Application Backdoor via Appium

Rajdeep Varma explained how you can use Appium scripts to call development code methods from test code.

He used Appium in this way because he was having a number of problems when trying to write tests:

  • System pop-ups were called and were not needed when running tests
  • Driver limits e.g. mocking the device has been shaken or changing time limits
  • Tests were slow to run

This is where he is using backdoors and where he thinks they could also be used:

  • Changing backend URLs
  • Changing app locale
  • Getting session ids from the app
  • Disabling “What’s new” pop-ups
  • Disabling client side A/B tests
  • Faking SIM card for payments
  • Get analytics data from the app to validate it

The biggest takeaway from this talk was to be careful not to use backdoor for every test case and call incorrect methods in order to make tests pass.

Mobile Peer 2 Peer Communication Testing

Canberk Akduygu gave us a talk about his challenges when automating the BIP app (it’s like the Turkish Whatsapp).

He was building an extended grid solution to change to the right version of Appium and set the desired capabilities within their testing framework according to properties set in a JSON config file.

His demo was the biggest takeaway which showed two phones messaging and even calling the other. It was one scenario that was running two different steps on each device. It showed that the test steps needed to be synchronised.

From a Software Tester to an Entrepreneur: What I’ve Learned

Kristel Kruustuk next came on stage and walked us through why she founded Testilio and her struggles with the company despite being so successful and growing at a fast pace since she began.

My takeaway from this talk to was investigate and get in touch with the Testilio team and see if they had any future plans for expanding from manual and automation testing to VR testing.

Appium: The Next Five Years

Jonathan Lipps gave the final talk and began again with the history of Appium but then spoke more in depth about the vision of the product over the next five years and hopeful milestones. Some of these things were:

  • StarDriver
  • InfinityDriver
  • Extension to the W3C WebDriver protocol
  • Node js base classes and libraries for easily writing new drivers

Closing Remarks

Lastly, we were treated to a performance featuring Jonathan Lipps, Appium and Selenium. I believe four or five instruments were being played by Appium, Selenium was outputting the lyrics and Jonathan was singing and playing the ukulele.

My biggest takeway from this is that Appium can be used in a variety of ways to perform a number of impressive tasks.

After Party

The after party was held at a bar a short walk from St Paul’s Cathedral. There I managed to talk to Ru Cindrea in more detail about the project I wanted to use the AltUnityTester for and whether she thought it would work. I also, managed to talk the ears off of both Charlene and Charlotte who were the speakers from the very first talk of the day.

Overall

I had a great day, met loads of wonderful people (including attendees and speakers) and I hope that next year, I’ll have begun using Appium for something that I do so I can share my own experiences with the community.

Quiz Scramble Template on Sale!

Earlier this year, I redeveloped my app Werdz Movies from UnityScript into C#.

This was just a first iteration. I redesigned the interface so that the hint is always on screen and I still need to add in the power-ups somewhere. These will eventually become in app purchases, something I never got around to doing in the released versions on the App Store and Google Play.

I designed this new version as a template with basic graphics so that anyone can use it and make it their own. After doing this, I packaged it all up and uploaded it to the Unity Asset Store.

This has been available since the 23rd October but from November 27th to December 8th PST it’ll be ON SALE!

You’ll be able to buy this with a massive discount of 30% off.

So if you’re interested in creating your own version of Werdz Movies maybe with games, historical figures or TV shows trivia, grab this now from the Asset Store. It’s only on sale for a short time so make the most of it.

 

Testing Your App Using TestFlight

TestFlight is a tool that I have yet to use during my development process. This has simply been because I haven’t been doing Beta testing in a structured way. But, I intend to change this going forward in my next and future projects.

As I researched TestFlight, I wrote short blog post on the subject for the audience of Simple Programmer.

Here’s my latest guest post for Simple Programmer, Testing Your App Using TestFlight.

Releasing Your App to the Store in Style Part 3

If you’ve read my story, you’ll know that I’ve been inspired to stop dreaming about my ideas and start doing something about them. Earlier this year, I incorporated the app development company Junction 5 Studios to house all of my efforts. This would also be a brand for me to build client work.

I used to think about myself as a novice within app development, but when I start talking about it to others, I realise that I have come a long way from nothing. Like John Sonmez says in the last step of his 10 Steps To Learning Anything Quickly course, you need to teach to really learn something.

I’ve found that the task of releasing an app after the many hours of developing and testing it, can be more effort than you initially thought. There’s so much to consider that I creating a series of guest posts on the Simple Programmer website giving you help and advice of how to configure your app store pages.

In part one, I started by dissecting the information you need to provide for the first screen, App Information. In part two, I walked you through what you need in order to continue building a great app store page for the second screen, Pricing and Availability.

In my final part I discuss app icons, keywords, images you’ll need for your marketing materials and everything else you need to configure before you can finally submit your app for review before you plan for that all-important release date.

So here it is, my latest post on Simple Programmer, Releasing Your App to the Store in Style Part 3.

Releasing Your App to the Store in Style Part 2

If you’ve read my story, you’ll know that I’ve been inspired to stop dreaming about my ideas and start doing something about them. Earlier this year, I incorporated the app development company Junction 5 Studios to house all of my efforts. This would also be a brand for me to build client work.
I used to think about myself as a novice within app development, but when I start talking about it to others, I realise that I have come a long way from nothing. Like John Sonmez says in the last step of his 10 Steps To Learning Anything Quickly course, you need to teach to really learn something.

I’ve found that the task of releasing an app after the many hours of developing and testing it, can be more effort than you initially thought.

In part one, I started by dissecting the information you need to provide for the first screen, App Information.

In my second post in this series, I’ll walk you through what you need in order to continue building a great app store page for the second screen, Pricing and Availability. Here’s my post to help you on Simple Programmer, Releasing Your App to the Store in Style Part 2.

Releasing Your App to the Store in Style Part 1

If you’ve read my story, you’ll know that I’ve been inspired to stop dreaming about my ideas and start doing something about them. Earlier this year, I incorporated the app development company Junction 5 Studios to house all of my efforts. This would also be a brand for me to build client work.

I used to think about myself as a novice within app development, but when I start talking about it to others, I realise that I have come a long way from nothing. Like John Sonmez says in the last step of his 10 Steps To Learning Anything Quickly course, you need to teach to really learn something.

I’ve found that the task of releasing an app after the many hours of developing and testing it, can be more effort than you initially thought. So, I thought I’d share a more detailed guide with you about the information you need to provide for the first screen. Here’s my post to help you on Simple Programmer, Releasing Your App to the Store in Style Part 1.

Instantiating uniquely named objects

So my first major hurdle in September left me stumped for ages.

Highlighting some of the challenges I faced when creating Project 1.

Task

I was trying to instantiate a grid of button game objects. Whenever a button is pressed, the object is destroyed and after x seconds it’s recreated in the same position. I managed to get this working with a single object, but not a grid of them.

Problem

Nothing was getting recreated when I clicked a button in the grid.

I was giving every button in the grid the same name when it was instantiated. So when I tried to check if the object was destroyed there were obviously multiple more on screen so nothing would get recreated.

Tasks towards a solution

I needed to try to:

  1. Name each object individually!
  2. Check for each object to see if it was destroyed
  3. Recreate the destroyed object

Using the tag property

For task one, I tried tag every object, but learned that tags can only be created in the editor, are used mostly to group objects of the same type (like the same type of button) and they are static. They can’t be created dynamically from code.

Using the name property

Next, I tried to give each object an individual name using the Name property. This worked great. I used a variable to count how many objects were being created, then used that variable to construct a unique name for the object.

Task one solved!

Checking a list

For task two, I decided to create a list of the named objects. Then I looped through the list to see if any are found then return a bool of the result. I could then use this to decide whether to call the recreate object method. Nice idea, but unfortunately the way I called this method led to a loop of only seeing that the first object had been destroyed.

Back to the keyboard with that then.

Lessons learned

So far, these are my takeaways from my first challenge.

    • How to use tags appropriately
    • The Tag and Name properties of game objects

<!–

  • The difference between local position and world/global position.

–>

Obviously, I need to overcome task two so I can focus on implementing the rest of the gameplay and releasing this as soon as possible.