Everybody Tests

When you go from building UiAutomator 1.0 tests in Eclipse as a stand-alone JAR over the last couple years to trying to use UiAutomator 2.0 within a product codebase with Gradle and nothing looks familiar... When you figure out why you were getting a null pointer exception after 2 days and it was all because of a copy-paste error... When you start trying to explain a tricky problem with a new test framework to the front-end developers on your project and it starts to feel like they're more spectators then collaborators... When you right-click on a test method and choose "Debug as..." and start debugging your UiAutomator test after all those months of needing to compile a JAR and edit a shell script prescribing which test case to run instead... When you can no longer use all those fantastically useful shell commands you were able to run in your UiAutomator 1.0 tests because 'adb shell uiautomator...' imparted sufficient permissions but 'adb

When you keep ramping up the event total count on your stress test because it mocks you by not resulting in crashes... When you join a legacy project and upon looking through their Gordian-knot of build dependencies realize that 90% of it is obsolete, yet subtly interdependent experimental code no longer included in the app (EWWWW)... When the project planners lowball the QA estimates because all they're doing is "throwing on a fresh coat of paint"... When that other team throws yet another party celebrating a routine bug-fix release...

New Android build system and test runner, same goose chase using undocumented features and hacks Oh, you thought they were ready to support full enterprise scale CI just because they moved to Gradle? As I've posted before, I am a big fan of Jenkins. It is extremely flexible, open source, and supported by a staggering array of plugins actively developed by engineers running over 100,000 instances of the server worldwide. With it's distributed node model, you can even build your own device cloud for hosting enterprise-scale automation , economizing hardware investments by sharing resources across multiple projects as well as speeding up automation by parallelizing test runs. I had been using a Jenkins-based system in the past to support instrumentation automation with Robotium quite happily. For the last couple years however, my work hasn't required that as much and I've found myself doing a lot more manual testing and using UiAutomator which didn't require