An app that existed even before Android existed!
Norris is a showcase for modern and well-crafted Android code.
Here you will find a codebase powered by tests in all semantic levels (unit, integration, acceptance) as well an architectural design that promotes discipline over state, using Kotlin Coroutines + Kotlin Flows as foundation for a pragmatic unidirectional dataflow implementation.
This project leverages on api.chucknorris.io as remote data source to implement the following use cases
- User can search for Chuck Norris facts and share them
- Application will offer suggestions of searches
- Application also remembers terms searched by the user
- OkHttp + Retrofit for networking
- Kotlinx.Serialization for Json handling
- Kotlinx.Coroutines for asynchrounous processing
- Unidirectional data-flow driven by Kotlin Flows
- Manual dependencies/instances management at runtime driven by Kodein
- No annotations processors (therefore no
- No Fragments
The code is structured in a multi-module fashion, with semantics of high-level modules (under
features) packaging high-level pieces of funcionality (including UI details) while low-level modules (or
platform ones) provide required infrastructure for features, like networking, storage and so on. The final product is packaged on top of the
This project is heavily opinionated on how testing should be done in modern Android projects. Particularly, I follow here the approach proposed by Kent Dodds as much as possible:
Write tests. Not too many. Mostly integration
approaching the concept of a honeycomb of tests the most I can.
In a nutshell :
- No mocks are used, only fakes when needed. This project does not use libraries like Mockito or Mockk.
- Most of unit tests actually are on
platformmodules, since these modules provide the core functionally for features
- Table-driven testing is used whenever possible
- Interaction-based tests are completely avoided; only state-based tests are used
features, tests are mandatory over data sources, although REST APIs are not directly faked; instead, we test the whole networking stack by inject fake responses on a Mock Server
- When a high level module owns some domain logic of interest - eg, some validation rule - such logic is unit tested
- No unit test over ViewModels
- Also on
features, integrated tests run at Activity level by leveraging a pragmatic way to decoupling this platform controller from its hosted Views : the inflated View is faked at testing time. Tests run on top of Robolectric over Activity Scenarios.
- In addition to that, on
featureswe test the View layer via screenshot tests in a fully isolated way. I see that screenshot tests are not the same and should not be used as acceptance tests.
- Acceptance tests are implemented with Espresso running over Android/Instrumentation
- Acceptance tests exercise the release artefact, approaching what will be shipped to users/customers; the only exception here is the REST API URL passed-in at build time (for the sake of controlling testing conditions)
- In addition to that, acceptance tests exercise real user flows in a cross-screen / cross-feature fashion and running with a stress-first approach (10 runs per test)
|Testing approach||Execution Environment||Amount||Percentage|
|Unit tests||JVM-only||10||~ 30%|
|Integration tests||JVM-only + Robolectric + Android/Instrumentation||21||~ 64%|
|Acceptance tests||Android/Instrumentation||2||~ 6%|
Building and Running
If you want a simple run over some task of the CI pipeline, just use the companion script
so you can chose between :
- Run static analysers (Ktlint and Detekt)
- Run all unit/integration tests over JVM
- Run all screenshot tests over Android/Instrumentation
- Run acceptance tests over with Espresso
Please note that an online device is required in order to run screenshot/acceptance tests . I recommend
pixel device profile as the your AVD configuration for that. Note that we have a companion
scripts/screenshots-sync.sh to sync images required for local screenshot testing.
Also note that local builds require JDK11, since this project compiles against Java11 bytecode.
In addition to that, this project requires latest stable release of Android Studio, ie, 7.x.z (Artic Fox) or newer.
- Mathias Schilling, for the Chuck Norris facts REST API
- Material Design Icons for the error states images
- Jetbrains for the amazing developer experience around Kotlin and Coroutines
- Someone in the Web for the Norris clipart
❤️(I'll be happy to put your name here, ping me!)
Coded by Ubiratan Soares (follow me on Twitter)
The MIT License (MIT) Copyright (c) 2019 Dotanuki Labs Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.