Project Name | Stars | Downloads | Repos Using This | Packages Using This | Most Recent Commit | Total Releases | Latest Release | Open Issues | License | Language |
---|---|---|---|---|---|---|---|---|---|---|
Kaspresso | 1,575 | 6 days ago | 3 | February 22, 2022 | 35 | apache-2.0 | Kotlin | |||
Android UI test framework | ||||||||||
Androidviewclient | 1,353 | 4 | 1 | 5 months ago | 262 | July 06, 2022 | 56 | apache-2.0 | Python | |
Android ViewServer and ADB client | ||||||||||
Adam | 339 | a month ago | 11 | May 19, 2021 | 2 | apache-2.0 | Kotlin | |||
Adam (or adm) is a coroutine-friendly Android Debug Bridge client written in Kotlin | ||||||||||
Mobileperf | 252 | 2 years ago | mit | Python | ||||||
Android performance test | ||||||||||
Chromedriver | 188 | 4 days ago | 2 | C++ | ||||||
Unofficial ChromeDriver mirror | ||||||||||
Auicrawler | 97 | 5 years ago | 5 | May 18, 2017 | 1 | Python | ||||
Android App UI自动遍历方案(有时比较忙,没有进一步开发,欢迎大家积极沟通&贡献) | ||||||||||
Stf Client | 45 | 3 years ago | 24 | August 31, 2019 | 4 | mit | Ruby | |||
Request devices from Smartphone Test Farm for adb connection | ||||||||||
Monkey_android | 34 | 5 years ago | Python | |||||||
stability test for android app | ||||||||||
Toster | 31 | 8 months ago | 5 | apache-2.0 | Kotlin | |||||
DSL framework for testing Android apps | ||||||||||
Calabash Android Server | 27 | 2 months ago | 6 | other | Java | |||||
Automated Functional testing for Android based on cucumber |
Kaspresso is a framework for Android UI testing. Based on Espresso and UI Automator, Kaspresso provides a wide range of additional features, such as:
And many more!
To integrate Kaspresso into your project:
mavenCentral
repository does not exist, include it to your root build.gradle
file:allprojects {
repositories {
mavenCentral()
}
}
build.gradle
:dependencies {
androidTestImplementation 'com.kaspersky.android-components:kaspresso:<latest_version>'
// Allure support
androidTestImplementation "com.kaspersky.android-components:kaspresso-allure-support:<latest_version>"
// Jetpack Compose support
androidTestImplementation "com.kaspersky.android-components:kaspresso-compose-support:<latest_version>"
}
If you are still using the old Android Support libraries, we strongly recommend to migrate to AndroidX.
The last version with Android Support libraries is:
dependencies {
androidTestImplementation 'com.kaspersky.android-components:kaspresso:1.0.1-support'
}
To make it easier to learn the framework, a step-by-step tutorial is available on our website.
We like the syntax that Kakao applies to write UI tests. This wrapper over Espresso uses the Kotlin DSL approach, that makes the code significantly shorter and more readable. See the difference:
Espresso:
@Test
fun testFirstFeature() {
onView(withId(R.id.toFirstFeature))
.check(ViewAssertions.matches(
ViewMatchers.withEffectiveVisibility(
ViewMatchers.Visibility.VISIBLE)))
onView(withId(R.id.toFirstFeature)).perform(click())
}
Kakao:
@Test
fun testFirstFeature() {
mainScreen {
toFirstFeatureButton {
isVisible()
click()
}
}
}
We used the same approach to develop our own wrapper over UI Automator, and we called it Kautomator. Take a look at the code below:
UI Automator:
val instrumentation: Instrumentation = InstrumentationRegistry.getInstrumentation()
val uiDevice = UiDevice.getInstance(instrumentation)
val uiObject = uiDevice.wait(
Until.findObject(
By.res(
"com.kaspersky.kaspresso.sample_kautomator",
"editText"
)
),
2_000
)
uiObject.text = "Kaspresso"
assertEquals(uiObject.text, "Kaspresso")
Kautomator:
MainScreen {
simpleEditText {
replaceText("Kaspresso")
hasText("Kaspresso")
}
}
Since Kakao and Kautomator provide almost identical APIs, you don’t have to care about what is under the hood of your tests, either Espresso or UI Automator. With Kaspresso, you write tests in the same style for both.
However, Kakao and Kautomator themselves don't help you to see the relation between the test and the corresponding test case. Also, a long test often becomes a giant piece of code that is impossible to split into smaller parts. That's why we have created an additional Kotlin DSL that allows you to read your test more easily.
See the example below:
@Test
fun shouldPassOnNoInternetScanTest() =
beforeTest {
activityTestRule.launchActivity(null)
// some things with the state
}.afterTest {
// some things with the state
}.run {
step("Open Simple Screen") {
MainScreen {
nextButton {
isVisible()
click()
}
}
}
step("Click button_1 and check button_2") {
SimpleScreen {
button1 {
click()
}
button2 {
isVisible()
}
}
}
step("Click button_2 and check edit") {
SimpleScreen {
button2 {
click()
}
edit {
flakySafely(timeoutMs = 7000) { isVisible() }
hasText(R.string.text_edit_text)
}
}
}
step("Check all possibilities of edit") {
scenario(
CheckEditScenario()
)
}
}
Sometimes your UI test passes ten times, then breaks on the eleventh attempt for some mysterious reason. It’s called flakiness.
The most popular reason for flakiness is the instability of the UI tests libraries, such as Espresso and UI Automator. To eliminate this instability, Kaspresso uses DSL wrappers and interceptors.
Let’s watch some short video that shows the difference between the original UI Automator (on the right) and the accelerated one (on the left).
Here is a short explanation of why it is possible.
We developed Kaspresso behavior interceptors on the base of Kakao/Kautomator Interceptors to catch failures.
Thanks to interceptors, you can do a lot of useful things, such as:
and many more (see the manual).
Kaspresso writes its own logs, detailed and readable:
Espresso and UI Automator don't allow to call ADB commands from inside a test. To fix this problem, we developed AdbServer (see the wiki).
You can use Kaspresso classes to work with Android System.
For example, with the Device
class you can:
(see more about the Device class).
If you develop an application that is available across the world, you have to localize it into different languages. When UI is localized, it’s important for the translator to see the context of a word or a phrase, that is the specific screen.
With Kaspresso, translators can automatically take a screenshot of any screen. It’s incredibly fast, even for legacy screens, and you don't have to refactor or mock anything (see the manual).
You can tune any part of Kaspresso (read more).
You can run your UI-tests on the JVM environment. Additionally, almost all interceptors improving stability, readability and other will work. Read more.
Kaspresso can generate very detailed Allure-reports for each test:
More information is available here.
Now, you can write your Kaspresso tests for Jetpack Compose screens! DSL and all principles are the same. So, you will not see any difference between tests for View screens and for Compose screens. More information is available here.
Keep in mind it's early access that may contain bugs. Also, API can be changed, but we are going to avoid it. Be free to create relative issues if you've encountered with any kind of problem.
The tool itself, even the perfect one, can not solve all the problems in writing UI tests. It’s important to know how to write tests and how to organize the entire process. Our team has great experience in introducing autotests in different companies. We shared our knowledge on Wiki.
For all information check Kaspresso wiki
All samples are available in the samples folder.
Most of the samples require AdbServer. To start AdbServer you should do the following steps:
Kaspresso
foldercd ~/Workspace/Kaspresso
adbserver-desktop.jar
java -jar artifacts/adbserver-desktop.jar
All existing issues in Kaspresso can be found here.
Breaking changes can be found here
Kaspresso is an open source project, so you are welcome to contribute (see the Contribution Guidelines).
Kaspresso is available under the Apache License, Version 2.0.