SMARTZOO-DEV

Download

smartzoo-dev@lists.man.poznan.pl

September 2013

6 participants
12 discussions

Fwd: [Epodreczniki] Fwd: [DL-Team] How the Google+ Team Tests Mobile Apps
by Bartosz Lewandowski 01 Sep '13

01 Sep '13

-- Treść oryginalnej wiadomości -- Temat: [Epodreczniki] Fwd: [DL-Team] How the Google+ Team Tests Mobile Apps Data: Sat, 31 Aug 2013 07:16:27 +0200 Nadawca: Marcin Werla (mobile) <mwerla(a)man.poznan.pl> Adresat: epodreczniki-pcss(a)lists.man.poznan.pl MoĹźe siÄ przyda. ------------------------------------------------------------------------ *Od:* Adam Dudczak <adam(a)geecon.org> *WysĹane:* Sat Aug 31 07:13:08 CEST 2013 *Do:* "Lista ZespoĹu Bibliotek Cyfrowych, (DziaĹ UsĹug Sieciowych PCSS)" <dl-team(a)lists.man.poznan.pl> *Temat:* [DL-Team] How the Google+ Team Tests Mobile Apps *How the Google+ Team Tests Mobile Apps* http://feedly.com/k/1coHOFt /by Eduardo Bravo Ortiz / âMobile firstâ is the motto these days for many companies. However, being able to test a mobile app in a meaningful way is very challenging. On the Google+ team we have had our share of trial and error that has led us to successful strategies for testing mobile applications on both iOS and Android. *General * Understand the platform. Testing on Android is not the same as testing on iOS. The testing tools and frameworks available for each platform are significantly different. (e.g., Android uses Java while iOS uses Objective-C, UI layouts are built differently on each platform, UI testing frameworks also work very differently in both platforms.) Stabilize your test suite and test environments. Flaky tests are worse than having no tests, because a flaky test pollutes your build health and decreases the credibility of your suite. Break down testing into manageable pieces. There are too many complex pieces when testing on mobile (e.g., emulator/device state, actions triggered by the OS). Provide a hermetic test <http://googletesting.blogspot.com/2012/10/hermetic-servers.html> environment for your tests. Mobile UI tests are flaky by nature; donât add more flakiness to them by having external dependencies. Unit tests are the backbone of your mobile test strat! egy. Try to separate the app code logic from the UI as much as possible. This separation will make unit tests more granular and faster. *Android Testing * *Unit Tests * Separating UI code from code logic is especially hard in Android. For example, an Activity is expected to act as a controller and view at the same time; make sure you keep this in mind when writing unit tests. Another useful recommendation is to decouple unit tests from the Android emulator, this will remove the need to build an APK and install it and your tests will run much faster. Robolectric <http://pivotal.github.io/robolectric/> is a perfect tool for this; it stubs the implementation of the Android platform while running tests. *Hermetic UI Tests * A hermetic UI test typically runs as a test without network calls or external dependencies. Once the tests can run in a hermetic environment <http://googletesting.blogspot.com/2012/10/hermetic-servers.html>, a white box testing framework like Espresso <http://www.youtube.com/watch?v=T7ugmCuNxDU> can simulate user actions on the UI and is tightly coupled to the app code. Espresso will also synchronize your tests actions with events on the UI thread, reducing flakiness. More information on Espresso is coming in a future Google Testing Blog article. *Diagram: Non-Hermetic Flow vs. Hermetic Flow * *Monkey Tests * Monkey tests look for crashes and ANRs <http://developer.android.com/training/articles/perf-anr.html> by stressing your Android application. They exercise pseudo-random <http://en.wikipedia.org/wiki/Pseudorandom_number_generator> events like clicks or gestures on the app under test. Monkey test results are reproducible to a certain extent; timing and latency are not completely under your control and can cause a test failure. Re-running the same monkey test against the same configuration will often reproduce these failures, though. If you run them daily against different SDKs, they are very effective at catching bugs earlier in the development cycle of a new release. *iOS Testing * *Unit Tests * Unit test frameworks like OCUnit <http://www.sente.ch/software/ocunit/>, which comes bundled with Xcode, or GTMSenTestcase <https://code.google.com/p/google-toolbox-for-mac/> are both good choices. *Hermetic UI Tests * KIF <https://github.com/kif-framework/KIF> has proven to be a powerful solution for writing Objective-C UI tests. It runs in-process which allows tests to be more tightly coupled with the app under test, making the tests inherently more stable. KIF allows iOS developers to write tests using the same language as their application. Following the same paradigm as Android UI tests, you want Objective-C tests to be hermetic. A good approach is to mock the server with pre-canned responses. Since KIF tests run in-process, responses can be built programmatically, making tests easier to maintain and more stable. *Monkey Tests * iOS has no equivalent native tool for writing monkey tests as Android does, however this type of test still adds value in iOS (e.g. we found 16 crashes in one of our recent Google+ releases). The Google+ team developed their own custom monkey testing framework, but there are also many third-party options available. *Backend Testing * A mobile testing strategy is not complete without testing the integration between server backends and mobile clients. This is especially true when the release cycles of the mobile clients and backends are very different. A replay test strategy can be very effective at preventing backends from breaking mobile clients. The theory behind this strategy is to simulate mobile clients by having a set of golden request and response files that are known to be correct. The replay test suite should then send golden requests to the backend server and assert that the response returned by the server matches the expected golden response. Since client/server responses are often not completely deterministic, you will need to utilize a diffing tool that can ignore expected differences. To make this strategy successful you need a way to seed a repeatable data set on the backend and make all dependencies that are not relevant to your backend hermetic. Using in-memory servers with fake data or an RPC replay to external dependencies are good ways of achieving repeatable data sets and hermetic environments. Google+ mobile backend uses Guice <https://code.google.com/p/google-guice/> for dependency injection, which allows us to easily swap out dependencies with fake implementations during testing and seed data fixtures. *Diagram: Normal flow vs Replay Tests flow * *Conclusion * Mobile app testing can be very challenging, but building a comprehensive test strategy that understands the nature of different platforms and tools is the key to success. Providing a reliable and hermetic test environment is as important as the tests you write. Finally, make sure you prioritize your automation efforts according to your team needs. This is how we prioritize on the Google+ team: Unit tests: These should be your first priority in either Android or iOS. They run fast and are less flaky than any other type of tests. Backend tests: Make sure your backend doesnât break your mobile clients. Breakages are very likely to happen when the release cycle of mobile clients and backends are different. UI tests: These are slower by nature and flaky. They also take more time to write and maintain. Make sure you provide coverage for at least the critical paths of your app. Monkey tests: This is the final step to complete your mobile automation strategy. Happy mobile testing from the Google+ team. shared via http://feedly.com ------------------------------------------------------------------------ DL-TEAM mailing list DL-TEAM(a)lists.man.poznan.pl https://lists.man.poznan.pl/mailman/listinfo/dl-team -- WysĹane za pomocÄ K-9 Mail.

1 0

Testy aplikacji
by Monika Rokosik 01 Sep '13

01 Sep '13

Hej, podczas naprawy crash'a AR potestowałam także inne ekrany aplikacji. Wykryłam kilka błędów. Wnioski z testów zamieściłam na confluence https://confluence.man.poznan.pl/community/pages/viewpage.action?pageId=274…. Pozdrawiam, Monika -- -- Monika Rokosik Poznańskie Centrum Superkomputerowo Sieciowe e-mail: mrokosik(a)man.poznan.pl

1 0