Testing: Ye Olde Way — ActivityInstrumentationTestCase2extends Activity> — Name of method to be tested starts with test — If something is temporarily broken, either delete it or comment it out.
Testing: Ye Olde Way — ActivityInstrumentationTestCase2extends Activity> — Name of method to be tested starts with test — If something is temporarily broken, either delete it or comment it out. — Testing different data requires a separate test calling a private helper.
Testing: Ye JUnit4 Way — Uses annotations instead of naming conventions — Allows tests to be marked as ignored — Runner has subclasses allowing all sorts of fancy things
Testing: Ye JUnit4 Way — Uses annotations instead of naming conventions — Allows tests to be marked as ignored — Runner has subclasses allowing all sorts of fancy things — Allows you to have tests skipped based on an assumption*
Testing: Ye JUnit4 Way — Uses annotations instead of naming conventions — Allows tests to be marked as ignored — Runner has subclasses allowing all sorts of fancy things — Allows you to have tests skipped based on an assumption* * - in theory
JUnit4 Benefits — Tests don't reference an activity unless they need to — Name things in a way that makes sense to YOU — Run the same test many times with different params
JUnit4 Drawbacks — !Assume.isWorkingRightNow() — FlakyTest does not work with JUnit4 tests. — You have to static import import static a lot more stuff.
Espresso: How work? — Hamcrest Matchers dig through the view hierarchy — Only considers the portions of the view immediately visible to the user — Can enter text, tap things, scroll, swipe out of the box
Espresso: How work? — Hamcrest Matchers dig through the view hierarchy — Only considers the portions of the view immediately visible to the user — Can enter text, tap things, scroll, swipe out of the box — Create your own actions
UI Testing Best Practices — Don't navigate through your entire UI every single time. — Use class and instance Before/After methods — Create a test class for each piece of your UI
UI Testing Best Practices — Don't navigate through your entire UI every single time. — Use class and instance Before/After methods — Create a test class for each piece of your UI — If there are things you can test without the UI, test them without the UI.
Other Tips for UI Testing — Make a mock flavor, and test on it — Feed your networking stack mock data (Mocktrofit) — Compare R.string string resources to what's on screen.
Other Tips for UI Testing — Make a mock flavor, and test on it — Feed your networking stack mock data (Mocktrofit) — Compare R.string string resources to what's on screen. — Remember when you need to scroll!
Other Tips for UI Testing — Make a mock flavor, and test on it — Feed your networking stack mock data (Mocktrofit) — Compare R.string string resources to what's on screen. — Remember when you need to scroll! — Get to a piece of your UI that's buried without having to tap 800 buttons yourself
designatednerd
tomohisa
toshiaizawa
tarao
motok1
iseki
smt7174
soachr
carta_engineering
kubukoz
oracle4engineer
jacopen
lara
brad_frost
mojombo
mthomps
3n
speakerdeck
brianwarren
garrettdimon
lemiorhan
myddelton
dougneiner
jennybc