<commit_before>---
layout: page
title: Take a Shot
summary: Summary goes here... just one line of summary
date: 2016-06-10
author: <NAME>
permalink: /blogs/:year/:month/:day/:title/
---

##Take a Shot

As a Mobile Developer there are a few aspects to my job that are especially rewarding. (Bet you can't guess).  Yes, contributing to an well-known app and working on new features that get 5-star reviews are nice.  But, perhaps greater than both is seeing all-green on my test suite.

That may sound lame initially, but think about it: if your app were used by millions of people, how much assurance would you want that it's doing what you intended? Anything to give more confidence to a dev team is worth pursuing and nothing quite gives our team confidence like a slew of green builds on a CI server  **\*\*Nerd Alert\*\* **

###You should be testing
Android developers have a lot to choose from these days to [test our apps](https://developer.android.com/studio/test/index.html).  There is jUnit for unit tests, Espresso and UI Automator for Integration tests, and even Monkey Testing for extra special circumstances.  But, have you also heard of Screenshot testing?  *(Hear more about how we test [here](https://www.youtube.com/watch?v=-xQCNf_5NNM))*  

It's actually just as it sounds: a screenshot test is one where a part of the UI is captured and compared to a known Master Copy.  If the images match, the test passes, if not, the test fails.  By being just-another-test, we're able to include them with all other tests and in our development process as a whole.

Obviously, we do this for the sake of app quality, but there are plenty of other reasons.

1. **Testing of the View Layer:**    Screenshot Tests are a good way to check all the states a particular View may be in so you can find layout bugs sooner.  Any UI element can be the target of a screenshot test and you can prime it with all sorts of test data and capture it.  You can render all kinds of character sets, ascenders/descenders, height and widths and verify that it looks just right.

2. **Better-than-Human Verification:**   Image processing libraries can perform diffs on pictures and detect if even 1 pixel changes.  Your 1-line change on one screen could affect an entirely different screen too and you may never know it until it's too late.  If you're about to refactor your UI layer, but don't want a visible change to the user, then screenshot testing will be invaluable.

3. **Auto Cataloging:**  Every screenshot can be saved as a test artifact and then displayed for all to see.  You don't have build and install an app to see what the current screen looks like, you can just send a URL! 

4. **A Picture is Worth 1024 words:**  Many times, teams work best off of screenshots for collaboration.  If screenshots are part of your test harness then they can be part of your Peer Review Process too.  We regularly pull in designers on PRs to get approval sooner and in context of the change.

Now that we all think we should be testing, how can we include this in everyday development?  

###Testing Locally<commit_msg>updated summary<commit_after>---
layout: page
title: Take a Shot
summary: Take a shot with Firebase Test Lab. In this post, we'll walkthrough how AMEX integrates Screenshot Testing with Firebase Test Lab to improve app quality
date: 2016-06-10
author: <NAME>
permalink: /blogs/:year/:month/:day/:title/
---

##Take a Shot

As a Mobile Developer there are a few aspects to my job that are especially rewarding. (Bet you can't guess).  Yes, contributing to an well-known app and working on new features that get 5-star reviews are nice.  But, perhaps greater than both is seeing all-green on my test suite.

That may sound lame initially, but think about it: if your app were used by millions of people, how much assurance would you want that it's doing what you intended? Anything to give more confidence to a dev team is worth pursuing and nothing quite gives our team confidence like a slew of green builds on a CI server  **\*\*Nerd Alert\*\* **

###You should be testing
Android developers have a lot to choose from these days to [test our apps](https://developer.android.com/studio/test/index.html).  There is jUnit for unit tests, Espresso and UI Automator for Integration tests, and even Monkey Testing for extra special circumstances.  But, have you also heard of Screenshot testing?  *(Hear more about how we test [here](https://www.youtube.com/watch?v=-xQCNf_5NNM))*  

It's actually just as it sounds: a screenshot test is one where a part of the UI is captured and compared to a known Master Copy.  If the images match, the test passes, if not, the test fails.  By being just-another-test, we're able to include them with all other tests and in our development process as a whole.

Obviously, we do this for the sake of app quality, but there are plenty of other reasons.

1. **Testing of the View Layer:**    Screenshot Tests are a good way to check all the states a particular View may be in so you can find layout bugs sooner.  Any UI element can be the target of a screenshot test and you can prime it with all sorts of test data and capture it.  You can render all kinds of character sets, ascenders/descenders, height and widths and verify that it looks just right.

2. **Better-than-Human Verification:**   Image processing libraries can perform diffs on pictures and detect if even 1 pixel changes.  Your 1-line change on one screen could affect an entirely different screen too and you may never know it until it's too late.  If you're about to refactor your UI layer, but don't want a visible change to the user, then screenshot testing will be invaluable.

3. **Auto Cataloging:**  Every screenshot can be saved as a test artifact and then displayed for all to see.  You don't have build and install an app to see what the current screen looks like, you can just send a URL! 

4. **A Picture is Worth 1024 words:**  Many times, teams work best off of screenshots for collaboration.  If screenshots are part of your test harness then they can be part of your Peer Review Process too.  We regularly pull in designers on PRs to get approval sooner and in context of the change.

Now that we all think we should be testing, how can we include this in everyday development?  

###Testing Locally
{'fraction_non_alphanumeric': 0.05415676959619953, 'fraction_numerical': 0.006334125098970704, 'mean_word_length': 4.000791765637372, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 4, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5097638', 'n_tokens_mistral': 1665, 'n_tokens_neox': 1548, 'n_words': 1047}