Talking about the development culture of Android

Quality is King

Yes, Google is famous for the execution of the king, but the quality of the king is actually more important things to do first.

Optimization of code with a low level of quality can lead to premature optimizations, and immature optimizations are the source of all evils (though not absolute, but in most cases).

Good news: Businesses like Square, SoundCloud, Twitter, and some developers are making Android development better by giving speeches, blogging, and thanking them! In addition, Google seems to have finally been interested in improving the quality of Android apps! Recently, Google participated in the Android Development Summit (Androiddevsummit) and some other meetings, we saw some of the content of the test, please keep it!

Now is the time to improve the quality of Android development.

Android development culture and documentation. 0. Fail fast mechanism: downtime as soon as possible, give up early.

Why do you say that? -Because you have to find the problem before the product arrives at the user, the sooner, the sooner the outage, the more favorable for you, in fact, this is what you should do.

Every item in this article will follow this basic principle.

1. Pull request, code review, and continuous integration

Project development should be done within the version control system. The development process should be through pull requests (hereinafter referred to as PRs) and code review, otherwise no code can be pushed directly to the main development branch. Each PR should trigger continuous integration (hereinafter referred to as the CI) system and build the project. Builds should be repeatable, and members of each team should be able to easily build projects.

Fail early: If the build of the PR fails in the CI system, the PR does not merge until the repair is complete.

2. Code Quality

Your code should be solid or strong. How you do this depends entirely on yourself. Code quality is not just about MVP/MVVM/MVC, but also about each line of code for each component in the APP. I prefer to use pure functions and immutable objects.

Fail early: Don't be the only developer in your project that can write maintainable code, make sure that other members can also write high-quality code (chat with them and discuss this article to inspire them!). ) to prevent bad code from being audited.

3. Static Code/Resource analysis

Static code analysis lets you find problems in your code before you enter the production environment. At the same time, it is also helpful for code auditing. Use tools such as Android Lint, FindBugs, PMD, SonarQube, and FB infer.

Fail early: Run a static analysis in CI, and when the configuration is installed, if a warning (not just an error message) appears in the project, discard the project as soon as possible.

4. Unit Testing

Yes! It's a test, right! Unit tests usually check that a function/object is doing its job correctly. The more tests in the project, the higher the Code coverage, and the more stable the APP's performance after release. In fact, unit tests can find most stupid bugs. Of course, if your App does data processing, unit testing will also help you keep your code working properly.

Easy Guide to Android Project Unit testing

1. I prefer to run unit tests on the JVM because it is much faster than running on the device/emulator.

2. The Android Gradle plugin can run unit tests on the JVM. Just add the test to it test/ java_or_other_lang .

3. You can run tests from the IDE (right-click Test-run) or from the ./gradlew test terminal.

4. You'll soon find out that if you run unit tests on the JVM, the Android SDK classes will be erased, and an exception will be thrown when they are triggered. It's pathetic, but it's repairable. If you need an Android SDK class, you can run it under the Robolectric Test Runner, Robolectric provides the most ways to implement the Android SDK class.

5. JUnit provides great testing tools and fairly good Rules concepts, but JUnit's assertions are not very useful. Tools such as ASSERTJ and Truth support assertions very well and can run under JUnit (or Testng/spock, etc.).

6. If you need to check behavior and copy some objects, you can use a copy library such as Mockito.

TDD or not, depends on you, but definitely worth a try!

Fail early: Run unit tests in CI and give up as soon as possible if some of the tests fail.

5. Code Coverage

Once you start writing unit tests, you need to know if code coverage is good enough. Tools like Jacoco can help you check the code path that the test program is taking. Code coverage is especially important if the code you are testing is dependent on a conditional statement, because you need to ensure that all possible code execution is checked.

You can enable Jacoco by using a apply plugin: ‘jacoco’ statement. You can jacocoReport configure which classes/packages should be checked through the Gradle task.

If coverage is not high enough, configure the Code overlay tool to discard the build project. If you are just beginning to use unit tests in an existing project, except for non-test classes, remove them from the exclusion list as soon as the test code can overwrite the classes. This rule can guarantee the coverage of the new code. Depending on the coverage report, you can discard the build using the jacoco-coverage plugin.

Fail early: Ensure code coverage is checked in the CI environment, and if the code coverage is not high enough, abandon the build as soon as possible.

6. Functional (UI) testing

That's right! More Tests. Functional testing checks the APP's functionality from the user's perspective. After a functional test starts the application, it verifies that certain features, such as whether the data that is loaded in the UI interface, are displayed correctly. Most of the work done by the QA team can be automated through functional testing, but that doesn't mean you don't need a QA team.

There are two basic ways to run a functional test, running in Android instrumentation or uiautomator. The main difference is that you can only interact with the application and have access to the program code when running the functional test in Android instrumentation. The tests performed in the Uiautomator run in the system process and interact with the application through the accessibility API (which has limited functionality compared to Android intrumentation). If you need to do interactive testing between applications and other applications-you can use Uiautomater. But typically, you can simulate such interactions and test them with Android instrmentation, and this kind of test doesn't have to rely on external factors.

Suggestions:

• Choose Android Instrumentation and Espresso first.
• The page-guided architecture in the test helps you write and maintain programs more quickly and easily (for example, when you have a page class that describes the application's screen or part of the screen).
• Interacting with back-end simulations will completely isolate the test program and run the tests in parallel, but also make sure that you do not share the state between the tests. Recommended Mockwebserver, very useful.
• The developer should write a functional test, yes, you read it right.
• Teach QA team to write functional tests-usually QA is different from the developer and knows what needs to be checked.
• Check the code coverage for the functional tests.

Fail early: Run the functional test in CI and discard the build project if some tests fail.

7. Integration Testing

Yes. is still a test. Typically, integration testing examines how different components of an application work together, including HTTP layers, the REST API layer, and the execution layer (RxJava, and so on).

Imagine a class that uses a bunch of other classes that loads data from the backend, processes it, and stores it in the database. Although you should cover each class with unit tests first, you can also use integration testing to override this complex test.

Here, the main difference from unit testing is that you are not using a simulated environment, but rather the actual implementation of the object in the test. You can simulate data transfer (MOCKWEBSERVER) and database status, then run real code to see how they work.

You can run the integration test on the Android instrumentation or JVM device/emulator because the test runs faster on the JVM-the author prefers the JVM.

Fail early: Run the integration test in CI and discard the project as early as possible if some of the tests fail.

8. Developer Settings menu (AKA: Debug drawer)

The Developer Settings menu in debug builds allows you to enable/disable tools such as Sthetho, Leakcanary, and tinydancer, simulate/alter the behavior of some applications, and so on.

changing and inspecting applications while the app is running, without rewriting the code, can save you and the QA team a lot of time.

The Fail early:leakcanary tool can help you to detect the problem before you receive a crash report from a real user. Teach your QA team to use similar tools for acceptance testing before each release.

That ' s it. The text ends.

Consider your development culture and discuss this topic with your team members, so that the development process and product quality you are building can be significantly improved.

Qualitymatters app

So, do you want to see a sample application that follows these guidelines? Click here to download Jake Wharton's U2020 in accordance with the above principles. Here's a qualitymatters app that follows the above principles.

I hope you can find some new ideas:

• Unit testing;
• Integration testing;
• Functional testing;
• static code analysis;
• Code coverage;
• Developer Settings menu;
• MVP, RxJava, Dagger 2 and Retrofit 2 and so on.

The Qualitymatters app will continue to maintain the update.

An open letter to Google

As previously said, #质量 > #表现

• Please send more information about the test!
• Please test (unit, integration, and functional testing) libraries and sample applications.
• Android needs to be Simulator, not Emulator, because robolectric ... Although undoubtedly, it is very useful, but there should be a better way.
• The combination of Google and the development community can improve the culture of Android development.

So, we need Android development culture!

Related reading:

• Enabling Android teams:tests? Ain ' t Nobody Got time for that! by Ty Smith
• Android Testing (Android Dev Summit 2015)
• Droidcon NYC 2015-debug builds:a New Hope
• Insights on Scaling Android development from Cyanogen, Amazon, Twitter, Square, Eventbrite, and more

Original address: http://artemzin.com/blog/android-development-culture-the-document-qualitymatters/

Reprint: http://www.ituring.com.cn/article/211200

Talking about the development culture of Android