This repo includes production ready samples that showcase my unopinionated way of simply writing military-grade bug-proof Jetpack Compose UI tests. EVERY single UI component, their possible behaviours and states were all tested!
With this repo, you can perform any kind of automated Jetpack Compose UI testing – i.e. you can test ANYTHING (both visible and invisible (i.e. things that are not visible on the UI but exists in the node – e.g. content description)) on the UI. For example, you can test whether or not a TextField’s trailing icon and/or it’s content description displays/exists on the UI.
If there is anything that’s not covered that you want to test, you can be able to create custom semantics in order to test ANYTHING on a Jetpack Compose UI!
So, READY! SET!! GO!!!
Project Tech-stack and Characteristics
- Android Framework
- Jetpack Compose
- Jetpack Compose Material Design 3 Components
- Jetpack Compose Material Design Extended Icons
- Kotlin Coroutine
- Reactive Programing
- UI Testing and Individual UI Component Testing
- Architecting Jectpack Compose UI Tests
- Composable Previews
- Extension Functions
- Custom semantics (for testing almost anything on the UI such as for asserting whether the leading icon of a TextField is displayed)
- Screenshot testing using Paparazzi including CI setup
- Always check and use the highest numbered version of a test case function as that is, in my opinion, the recommended one to use. But you can choose which ever version of the test case function you preferred.
- For a more structured way of testing, it’s highly recommended to use the test classes with the highest number suffixed on the file/class name.
The name MilitaryJet has NO connection whatsoever with a military/army/jet fighters. The “Jet” in MilitaryJet is from JETpack Compose and “Military” in MilitaryJet is from MILITARY-grade from this repo’s description which means the level of fight against computer software bugs. And then the MilitaryJet is the level of weaponry in the fight against Jetpack Compose UI bugs.
Too many comments. For example, some comments are just for sample purposes for someone who might be interested in a particular test case. Note that newer test classes with higher numbers suffixed in their names have very fewer and necessary comments.
Mobile App Development Best Practices – 21.09
iOS Closures vs. Delegates in Swift iOS How to use the new inspector SwiftUI view modifier How to create an...
2023 App Threat Report
In 2022 alone, the number of mobile app downloads surpassed a staggering 200 billion, emphasizing the pervasive presence of these...
ElectricSQL – Local-first sync layer for web and mobile apps
Local-first sync layer for web and mobile apps. Build reactive, realtime, local-first apps directly on Postgres. What is ElectricSQL? ElectricSQL...
GitHub Copilot Chat opened to individual developers
Like similar chatbots, Copilot Chat sits in the sidebar of the IDE, and developers can use it to have lengthy...
ComposeCard – A beautifully designed payment view library
ComposeCards is a beautifully designed payment view library for Credit and Debit Cards. Made using Jetpack Compose 🎉. It allows...
Mobile App Development Best Practices – 20.09
Airship has released another study of mobile users aka shoppers. A lot of interesting things about habits and tasks in...