Today is my chance.<\/p>\n
TestProject Experiment Number Two<\/h2>\n
After my success playing with recorded test automation (I really want to call this recorded test assistance<\/i>) for web, I decided to try the same thing using TestProject<\/a> to test a mobile application.<\/p>\n I was mentally prepared to install the Android SDK (or at least ADB), and spend a bunch of time getting a connection set up, but holy crap – was it always this easy?<\/i><\/p>\n I already have the TestProject agent running on my computer (for running the web tests), so all I had to do was select Android as my target, and everything else just worked.<\/p>\n Overall, the setup wizard is extremely easy to follow, and worked amazingly well. My phone was already in developer mode, so all I had to do was configure USB debugging, (optionally) disable a few animation features (for testability), and the TestProject web app connected to my phone and showed a mirror on screen in seconds. I thought for sure that I\u2019d spend an hour or more getting this going, but I was wrong.<\/p>\n Granted – I don\u2019t have much experience here other than half a dozen sessions debugging over ADB, so this sort of thing may be the norm now, so all I can say is setting up a remote development session can\u2019t get much better than this.<\/p>\n The wizard is pretty much the same as the web wizard with one cool addition. Once the connection is configured, I can browse the device packages to choose which one I want to test:<\/p>\n I decided it would be fun to play with some automation for the Twitter app. There\u2019s an option to reset the app before starting, and there\u2019s even a default step added to reset, but for my experiment, I deleted that step.<\/p>\n As in my tests on angryweasel.com, I\u2019m just going to record selecting the top 4 elements from right to left and see what happens.<\/p>\n Note that the steps here are able to pull more friendly names from the package, so the test steps are pretty readable as is.<\/p>\n Using the same test strategy as I did with web tests, I then added validation to ensure that the correct screen showed in the right place.<\/p>\n For each screen, I just used the \u201cValidations\u201d design element to confirm the existence of a particular control. There are probably better ways to do this, but for my quick test, it\u2019s fine.<\/p>\n Similar to what I wrote for web tests, I have some actions with validation.<\/p>\n If you\u2019ve written automation in Appium or Selenium (or other frameworks that rely on IDs, XPaths, etc.) you are already familiar with the game we play to find elements.<\/p>\n One of the other handy features of TestProject is a simple, but useful element locator that makes it easy to discover if the element you\u2019re working with is currently visible. In the example below, I\u2019ve clicked the Find button in the test designer to show me the Twitter Home button.<\/p>\n Pretty cool!<\/p>\n As a nice aside, notice that the screenshot above (unlike the other screenshots), my phone screen fills the emulator (vs. the other screenshots where it fills 70% or so of the emulator screen). The TestProject team fixed the issue practically moments after I reported it.<\/p>\n Let me be the first to point out that this isn\u2019t particularly great<\/i> automation, and that the validation I\u2019m doing probably isn\u2019t what needs to be tested at the UI level for Twitter.<\/p>\n When you<\/u><\/i> write UI automation, use it to find bugs that can only be found at the UI level. If it\u2019s a special visual effect that can only be detected via human eyes, then use human eyes to validate the effects.<\/p>\n Of equal importance is your strategy. Don\u2019t start by deciding what to automate. Instead, start with what you want to test<\/i> – and then use automation to assist your testing. I\u2019ll refer again to my article on the TestProject site<\/a> that expands on these ideas in more depth.<\/p>\n All that said, it seems to me that I could very well use TestProject for proper<\/i> targeted UI tests where they were needed, and that it would serve me well.<\/p>\n I\u2019m still surprised by how easy it was to get up and running testing a mobile app, and the test steps were pretty straightforward and intuitive.<\/p>\n One of the areas where mobile automation really helps is in making sure applications work across a variety of devices. I only have one phone, but TestProject does support working with multiple connected devices to a single desktop. You just connect a USB Hub with a suite of devices, and you have an instant test lab. It\u2019s also worth mentioning that an account can have multiple agents assigned to it. This enables executing tests not only on your desktop (and devices connected to it), but also on remote agents (and devices connected to them) in different locations anywhere in the world. It could be fun to see if TestProject could target a big virtual and real mobile test farm like BitBar<\/a>, but there\u2019s plenty of flexibility and potential right out of the box.<\/p>\n As with the web tests, I\u2019d love to see a way to view \/ edit the underlying code, but my curiosity was less with mobile apps – perhaps because my knowledge of Appium is much less than my knowledge of Selenium.<\/p>\n Overall, it seems like a pretty usable and robust choice for most mobile automation tasks.<\/p>\n One more investigation to go where I\u2019ll see how TestProject does with some coded tests.<\/p>\n As I type this, I realize I have a mildly embarrassing gap in my testing career. I don\u2019t recall ever writing any automation for mobile applications. Maybe that\u2019s not exactly true – nearly 20 years ago, I wrote some automation in C++ to test Windows CE, and some applications that ran on it…and technically that…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[1],"tags":[],"class_list":["post-1410","post","type-post","status-publish","format-standard","hentry","category-allposts"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/1410","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/comments?post=1410"}],"version-history":[{"count":3,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/1410\/revisions"}],"predecessor-version":[{"id":1429,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/posts\/1410\/revisions\/1429"}],"wp:attachment":[{"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/media?parent=1410"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/categories?post=1410"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/angryweasel.com\/blog\/wp-json\/wp\/v2\/tags?post=1410"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Getting Started – The Setup<\/h3>\n
![\"\"](\"https:\/\/angryweasel.com\/blog\/wp-content\/uploads\/2018\/08\/null-13.png\" "\\"\\"")
<\/p>\n![\"\"](\"https:\/\/angryweasel.com\/blog\/wp-content\/uploads\/2018\/08\/null-14.png\" "\\"\\"")
<\/p>\nCreating Tests<\/h3>\n
![\"\"](\"https:\/\/angryweasel.com\/blog\/wp-content\/uploads\/2018\/08\/null-15.png\" "\\"\\"")
<\/p>\n![\"\"](\"https:\/\/angryweasel.com\/blog\/wp-content\/uploads\/2018\/08\/null-16.png\" "\\"\\"")
<\/p>\nThe Element Locator<\/h3>\n
![\"\"](\"https:\/\/angryweasel.com\/blog\/wp-content\/uploads\/2018\/08\/null-17.png\" "\\"\\"")
<\/p>\nA Few Words About Automation<\/h3>\n
Observations<\/h2>\n
<\/h2>\n","protected":false},"excerpt":{"rendered":"