Testify — Android Screenshot Testing

Overview

Testify — Android Screenshot Testing

Add screenshots to your Android tests

GitHub Actions Maven Central Maven Central

Expand your test coverage by including the View-layer. Testify allows you to easily set up a variety of screenshot tests in your application. Capturing a screenshot of your view gives you a new tool for monitoring the quality of your UI experience. It's also an easy way to review changes to your UI. Once you've established a comprehensive set of screenshots for your application, you can use them as a "visual dictionary". In this case, a picture really is worth a thousand words; it's easy to catch unintended changes in your view rendering by watching for differences in your captured images.

Testify screenshot tests are built on top of Android Instrumentation tests and so integrate seamlessly with your existing test suites. You can run tests and capture screenshots from within Android Studio or using the Gradle command-line tools. Testify also works well with most Continuous Integration services.

You can easily capture screenshots with different resolutions, orientations, API versions and languages by simply configuring different emulators. Testify natively supports grouping screenshot tests by device characteristics. Testify captures a bitmap of your specified View after all layout and draw calls have completed so you know that you're capturing an authentic rendering representative of what your users will see in your final product.

Set up Testify

Before building your screenshot test with Testify, make sure to set a dependency reference to the Testify plugin:

Root build.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "com.shopify.testify:plugin:1.2.0-alpha01"
    }
}

Application build.gradle

plugins {
    id("com.shopify.testify")
}

dependencies {
    androidTestImplementation "androidx.test:rules:1.4.0"
}

Device Configuration

It is required for you to turn off animations on your test device — leaving system animations turned on in the test device might cause synchronization issues which may lead your test to fail. Turn off animations from Settings by opening Developer options and turning all the following options off:

  • Window animation scale
  • Transition animation scale
  • Animator duration scale

You can find a recommended emulator configuration here.

Android Studio Plugin

Testify screenshot tests are built on top of Android Instrumentation tests and so already integrate seamlessly with existing test suites. Screenshots can be captured directly from within Android Studio or using the Gradle command-line tools.

However, the current Android Studio support relies fully on the fact that Testify tests extend ActivityTestRule and can be invoked using the built-in support for running instrumentation tests with various commands (notably sidebar icons) in Android Studio. These are limited to run and debug commands. Android Studio has no concept of recording or pulling screenshots from the device. Thus, it requires developers to drop to the Gradle Panel or command-line to fully use Testify.

With the installation of an an Intellij-platform plugin, many common Testify actions can be seamlessly integrated into your IDE. The Testify Android Studio plugin is available for Android Studio version 4.0 through 4.2 via the Intellij Marketplace.

Get from Marketplace

Write a test

Testify is a subclass of Android's ActivityTestRule. The testing framework launches the activity under test before each test method annotated with @Test and before any method annotated with @Before.

Each screenshot test method must be annotated with the @ScreenshotInstrumentation annotation.

Within your test method, you can configure the Activity as needed and call assertSame() to capture and validate your UI. The framework handles shutting down the activity after the test finishes and all methods annotated with @After are run.

@RunWith(AndroidJUnit4::class)
class MainActivityScreenshotTest {

    @get:Rule var rule = ScreenshotRule(MainActivity::class.java)

    @ScreenshotInstrumentation
    @Test
    fun default() {
        rule.assertSame()
    }
}

For additional testing scenarios, please refer to the recipe book.

Update your baseline

Testify works by referencing a PNG baseline found in your androidTest/assets directory for each test case that you write. As you write and run tests, an updated baseline image is maintained on your device or emulator. In order to update the baseline, you need to copy or pull the image from the device to your local development environment. Testify offers a variety of Gradle tasks to simplify the copying of your baseline images.

Record a new baseline

Run all the screenshot tests in your app and update the local baseline.

./gradlew screenshotRecord

Verify the tests

Run all the screenshot tests in your app and fail if any differences from the baseline are detected.

./gradlew screenshotTest

Pull images from the device

Copy images from the app_images directory on your emulator to your local androidTest/assets directory.

./gradlew screenshotPull

Erase any existing images from the device

Clear any baseline images that may be remaining on your emulator.

./gradlew screenshotClear

Generate a YAML test report

You can optionally generate a YAML test report for offline parsing by adding to your AndroidManifest.xml. Once enabled, Testify will create a report.yml cataloging the statistics about the most recent test run. You can view the report with:

./gradlew reportShow

You can copy the report.yml file to your local project directory with:

./gradlew reportPull

There are a variety of additional Gradle commands available through the Testify plugin. For advance usage, please refer to the Plugin guide.

License

MIT License

Copyright (c) 2021 Shopify

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.
Comments
  • A way to run all the tests and ignore the ones that have the ScreenshotInstrumentation annotation

    A way to run all the tests and ignore the ones that have the ScreenshotInstrumentation annotation

    Is your feature request related to a problem? Please describe. A way to run all connectedAndroidTests in the project (running all the modules tests) but ignore the screenshot tests

    Describe the solution you'd like The same way we can run only ./gradlew screenshotTest, have a way to ignore all that have the ScreenshotInstrumentation annotation

    Feedback 
    opened by joao-sixtostart 2
  • Update the testify.dev landing page to something nicer

    Update the testify.dev landing page to something nicer

    Is your feature request related to a problem? Please describe.

    I like this: https://insert-koin.io/

    This feedback relates to:

    • [ ] The Kotlin library
    • [ ] The Gradle plugin
    • [ ] The IntelliJ Platform plugin
    • [ ] The sample code
    • [ ] The documentation

    Describe the solution you'd like A clear and concise description of what you want to happen.

    Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

    Additional context Add any other context or screenshots about the feature request here.

    Feedback 
    opened by DanielJette 2
  • Issue-8, Issue-33: Add support for Android Studio Chipmunk and Dolphin

    Issue-8, Issue-33: Add support for Android Studio Chipmunk and Dolphin

    What does this change accomplish?

    Resolves #8 Resolves #31 Resolves #33

    ⚠️ I merged https://github.com/ndtp/android-testify/pull/38 into this branch. That code has already been reviewed.

    For this PR, you need only review the following commits:

    • 6dc805e0f86722ef573a08e145d11a888b8ba4cb
    • 8d682c7683864303d747cea7d38e72197a539579
    • 87c84c331f9bd7adf3d98bead0db7dcf0a912100
    • 6a3cdcae9e1697fce3ed8b999ac9ef59d49783e1
    • 4d0053e1905d230c40c4f77049f2fdef3448ab67

    How have you achieved it?

    The main bug was that the ktFile module name now includes the test variant (androidTest) as a suffix. This needs to be trimmed to match the expected Gradle project name.

    However, I had to make a lot of changes to the build.gradle file for the IntelliJ plugin because bumping the target IntelliJ version started building against newer IC library versions and pretty much nothing compiled. So, I refactored the build to use explicit variables for the compile and run instances of Android Studio. This makes it easy to build against a fixed version of the IntelliJ platform while testing against any given installation of Android Studio.

    Tophat instructions

    1. Check out this branch bugfix/33/android-studio-213
    2. Download Dolphin or Chipmunk from https://developer.android.com/studio/preview
    3. Edit ./Plugins/IntelliJ/gradle.properties and change the StudioRunPath to point to your Android Studio installation from step 2
    4. Run ./gradlew IntelliJ:buildPlugin IntelliJ:runIde
    5. Open the Sample source code in the preview build of Android Studio
    6. Verify that the 📷 icon is present in the screenshot test files and that the various commands work as expected.

    Or, you can install the pre-built plugin from IntelliJ-1.2.0-alpha01.jar.zip

    opened by DanielJette 2
  • Building IntelliJ plugin on aarch64 fails

    Building IntelliJ plugin on aarch64 fails

    Describe the bug Attempting to build the IntelliJ on an Apple arm64 device fails due to the dependencies being unable to resolve aarch64 related resources.

    This issue relates to:

    • [ ] The Kotlin library
    • [ ] The Gradle plugin
    • [x] The IntelliJ Platform plugin
    • [ ] The sample code
    • [ ] The documentation

    To Reproduce Steps to reproduce the behavior:

    1. Using changes from https://github.com/ndtp/android-testify/pull/6
    2. ./gradlew IntelliJ:buildPlugin
    3. See stacktrace similar to 👇
    > Task :IntelliJ:buildSearchableOptions
    [gradle-intellij-plugin :IntelliJIntelliJ:IntelliJ:buildSearchableOptions] Error when resolving dependency: DefaultExternalModuleDependency{group='com.jetbrains', name='jbre', version='jbr_jcef-11_0_6-osx-aarch64-b765.25', configuration='default'}
    org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException: Could not resolve all files for configuration ':IntelliJ:detachedConfiguration6'.
    	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.rethrowFailure(DefaultConfiguration.java:1282)
    	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$1700(DefaultConfiguration.java:139)
    	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.visitArtifacts(DefaultConfiguration.java:1259)
    	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.visitContents(DefaultConfiguration.java:1252)
    	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.visitContents(DefaultConfiguration.java:480)
    	at org.gradle.api.internal.file.AbstractFileCollection.getFiles(AbstractFileCollection.java:126)
    	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getFiles(Unknown Source)
    	at org.jetbrains.intellij.utils.DependenciesDownloader.downloadFromMultipleRepositories(DependenciesDownloader.kt:36)
    	at org.jetbrains.intellij.utils.DependenciesDownloader.downloadFromRepository(DependenciesDownloader.kt:23)
    	at org.jetbrains.intellij.jbr.JbrResolver.getJavaArchive(JbrResolver.kt:163)
    	at org.jetbrains.intellij.jbr.JbrResolver.resolve(JbrResolver.kt:138)
    	at org.jetbrains.intellij.jbr.JbrResolver$resolveRuntime$5.invoke(JbrResolver.kt:102)
    	at org.jetbrains.intellij.jbr.JbrResolver$resolveRuntime$5.invoke(JbrResolver.kt:24)
    	at org.jetbrains.intellij.jbr.JbrResolver$resolveRuntime$7.invoke(JbrResolver.kt:127)
    

    Expected behavior

    Can build cleanly on Apple Silicon.

    Desktop (please complete the following information):

    • OS: macOS arm64
    Bug 
    opened by jaredh 2
  • Update the testify.dev landing page to something nicer

    Update the testify.dev landing page to something nicer

    Is your feature request related to a problem? Please describe.

    I like this: https://insert-koin.io/

    This feedback relates to:

    • [ ] The Kotlin library
    • [ ] The Gradle plugin
    • [ ] The IntelliJ Platform plugin
    • [ ] The sample code
    • [ ] The documentation

    Describe the solution you'd like A clear and concise description of what you want to happen.

    Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

    Additional context Add any other context or screenshots about the feature request here.

    Feedback 
    opened by DanielJette 2
  • Issue-12: Add migration documentation

    Issue-12: Add migration documentation

    What does this change accomplish?

    Resolves #12

    How have you achieved it?

    This PR adds a brief migration guide explaining how to upgrade from the Shopify to dev.testify release.

    Future PRs will expand on the migration guide to explain how to move fully to the 2.* architecture.

    You can view the rendered migration guide here https://ndtp.github.io/android-testify/

    Tophat instructions

    image image
    opened by DanielJette 1
  • Issue-12: Add initial Docusaurus documentation

    Issue-12: Add initial Docusaurus documentation

    What does this change accomplish?

    This PR adds the initial version of the Docusaurus documentation. The documentation is a direct port of the documentation currently found in markdown files.

    These documents represent a snapshot of the 1.2.0-alpha01 documentation and will eventually be versioned as such and replaced with updated 2.* documentation.

    Please review https://ndtp.github.io/android-testify/ and report broken links or any navigation problems.

    opened by DanielJette 1
  • Issue-43: IntelliJ plugin supports both new and legacy package names

    Issue-43: IntelliJ plugin supports both new and legacy package names

    What does this change accomplish?

    Add support for both new and legacy package names to the IntelliJ plugin. Resolves #43

    How have you achieved it?

    Users will likely take some time to migrate from the com.shopify namespace to the new dev.testify namespace. During this transition, they may be using newer versions of Android Studio (Dolphin, Electric Eel) which are not supported by the legacy plugin. To facilitate this transition, the plugin can support both new and legacy package names.

    Tophat instructions

    1. In any supported version of Android Studio, install the pre-built plugin from IntelliJ-1.2.0-alpha02.jar.zip

    New package

    1. Open the current Sample source code in the preview build of Android Studio.
    2. Verify that the 📷 icon is present in the screenshot test files and that the various commands work as expected.

    Legacy Package

    1. Checkout the legacy codebase from https://github.com/Shopify/android-testify
    2. Open the legacy project Sample
    3. Verify that the 📷 icon is present in the screenshot test files and that the various commands work as expected.
    opened by DanielJette 1
  • Request: Add the ability to screenshot the entire screen

    Request: Add the ability to screenshot the entire screen

    Is your feature request related to a problem? Please describe.

    Not just the View or Window, but the entire screen including the navigation UI and status bar (dialogs, menus and popups too).

    Library 
    opened by DanielJette 1
  • Feature Request: Extensible capture and diff algorithms

    Feature Request: Extensible capture and diff algorithms

    Is your feature request related to a problem? Please describe.

    I'd like to be able to provide a custom capture method or diff algorithm. The stock capture methods (eg. PixelCopy) and diff methods (e.g. sameAs) are not sufficient for all cases. It would be nice to be able to define my own.

    This feedback relates to:

    • [x] The Kotlin library
    • [ ] The Gradle plugin
    • [ ] The IntelliJ Platform plugin
    • [ ] The sample code
    • [ ] The documentation

    Describe the solution you'd like

    screenshotTestRule
        .setCaptureMethod { activity, _ ->
            // Capture the entire Window, not just the activity
            PixelCopy.request( activity.window, ... )
        }
        .setBitmapCompare { baselineBitmap, currentBitmap ->
            // Check if the bitmaps have an alpha channel
            baselineBitmap.hasAlpha() && currentBitmap.hasAlpha()
        }
    

    Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

    Additional context Add any other context or screenshots about the feature request here.

    Feedback Library 
    opened by DanielJette 1
  • 95 resource configuration for compose activity 2.0.0 alpha02

    95 resource configuration for compose activity 2.0.0 alpha02

    What does this change accomplish?

    ComposableTestActivity now supports resource wrapping. This means that Testify can configure the font scale and locale for tests. Compose screenshot tests will now respect the locale and fontScale configuration parameters. Usage:

    rule
        .setCompose {
            Text("Example")
        }
        .setLocale(Locale.FRANCE)
        .setFontScale(2.0f)
    
    opened by DanielJette 0
  • Screenshot different on M1 vs x64 devices

    Screenshot different on M1 vs x64 devices

    Describe the bug

    • Running the same screenshot test on a Macbook Pro with M1 chip vs. Intel x64 results in failing tests. The diff between these two recordings look identical content wise so it seems like it's some sizing or some other thing that is off.
    • In order to get around this issue I tried to use the setUseSoftwareRenderer(true) as suggested in the doc to ignore the architecture differences but it didn't seem to help
    • Also tried to reduce the exactness of each failing test to see if I could lower the tolerance to get it to pass but this turned out to be a bit of a flaky test as each time I run it different sets seem to fail, some errors such:
            at dalvik.system.VMStack.getThreadStackTrace(Native Method)
            at java.lang.Thread.getStackTrace(Thread.java:1720)
            at androidx.test.espresso.base.DefaultFailureHandler.getUserFriendlyError(DefaultFailureHandler.java:12)
            at androidx.test.espresso.base.DefaultFailureHandler.handle(DefaultFailureHandler.java:7)
            at androidx.test.espresso.ViewInteraction.waitForAndHandleInteractionResults(ViewInteraction.java:8)
            at androidx.test.espresso.ViewInteraction.desugaredPerform(ViewInteraction.java:11)
            at androidx.test.espresso.ViewInteraction.perform(ViewInteraction.java:4)
            at androidx.test.espresso.Espresso.closeSoftKeyboard(Espresso.java:1)
            at dev.testify.ScreenshotRule.assertSame(ScreenshotRule.kt:493)
    

    This issue relates to:

    • [X] The Kotlin library
    • [ ] The Gradle plugin
    • [ ] The IntelliJ Platform plugin
    • [ ] The sample code
    • [ ] The documentation

    To Reproduce Steps to reproduce the behavior:

    1. Use an M1 device to record a screenshot.
    2. Confirm it passes on its own device
    3. Re-run the same passing test on a non-M1 device
    4. See a failing test when expecting a pass

    Expected behavior Expect the screenshots to pass regardless of the architecture of the processor of a device

    Desktop (please complete the following information):

    • OS: macOS
    • Version 13.0.1

    Target Android Device (please complete the following information):

    • Device: Pixel 3a
    • Physical or Virtual: Android Virtual Device (Emulator)
    • API Level: 29
    • Testify Key: 29-1080x2220@440dp-en_US
    Bug 
    opened by matthew-shin-hootsuite 17
  • [ComposableScreenshotRule] API 33 -- android.content.ActivityNotFoundException: Unable to find explicit activity class

    [ComposableScreenshotRule] API 33 -- android.content.ActivityNotFoundException: Unable to find explicit activity class

    Describe the bug

    As of API 33, you can no longer run screenshot test that use ComposableTestActivity. It seems that Google changed what is allowable in the manifest entries for Activities. The ComposableTestActivity is defined as part of the androidTest configuration, and so is not visible in the debug build flavor of the app. We need a solution that will make that Activity visible to the app.

    This issue relates to:

    • [ ] The Kotlin library
    • [x] Compose Extension Library
    • [ ] The Gradle plugin
    • [ ] The IntelliJ Platform plugin
    • [ ] The sample code
    • [ ] The documentation

    To Reproduce

    1. Configure an emulator using API 33
    2. Run the sample tests (./gradlew sample:screenshotTest)

    Results:

    android.content.ActivityNotFoundException: Unable to find explicit activity class {com.servicetitan.work.debug.test/androidx.test.core.app.InstrumentationActivityInvoker$BootstrapActivity}; have you declared this activity in your AndroidManifest.xml, or does your intent not match its declared <intent-filter>?
            at android.app.Instrumentation.checkStartActivityResult(Instrumentation.java:2158)
            at android.app.Instrumentation.execStartActivity(Instrumentation.java:1805)
            at androidx.test.runner.MonitoringInstrumentation.execStartActivity(MonitoringInstrumentation.java:603)
            at android.app.ContextImpl.startActivity(ContextImpl.java:1101)
            at android.content.ContextWrapper.startActivity(ContextWrapper.java:454)
            at androidx.test.core.app.InstrumentationActivityInvoker.startActivity(InstrumentationActivityInvoker.java:431)
            at androidx.test.core.app.InstrumentationActivityInvoker.startActivity(InstrumentationActivityInvoker.java:437)
            at androidx.test.core.app.ActivityScenario.launchInternal(ActivityScenario.java:265)
            at androidx.test.core.app.ActivityScenario.launch(ActivityScenario.java:195)
            at androidx.test.ext.junit.rules.ActivityScenarioRule.lambda$new$0$ActivityScenarioRule(ActivityScenarioRule.java:70)
            at androidx.test.ext.junit.rules.ActivityScenarioRule$$Lambda$0.get(ActivityScenarioRule.java:70)
            at androidx.test.ext.junit.rules.ActivityScenarioRule.before(ActivityScenarioRule.java:103)
            at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
    

    Expected behavior

    Tests should run as expected.

    Desktop (please complete the following information):

    • OS: macOS
    • Version 12.2.1

    Target Android Device (please complete the following information):

    • Device: Any
    • Physical or Virtual: Any
    • API Level: 33 (error does not occur on 32 or earlier)
    • Testify Key: 33-1080x2280@440dp-en_US
    Bug Testify 2.0 Extension 
    opened by djette-st 0
  • [2.0] ScreenshotTestRule should be backwards compatible

    [2.0] ScreenshotTestRule should be backwards compatible

    Build on the concepts from https://github.com/ndtp/android-testify/compare/issue-60/java-builder (ConfigurationBuilder) and provide an API-compatible set of extensions for Testify 2.0 so that legacy code does not need to be migrated to the configure {} pattern immediately.

    Feedback Library Testify 2.0 Architecture 
    opened by DanielJette 0
  • [2.0] Configure should be generic

    [2.0] Configure should be generic

    The new configure method should return a generic.

    Configure always returns a ScreenshotTest<T> but this means that subclasses of the Rule (like ComposableScreenshotRule) must be invoked prior to configure. It breaks the logical flow of the test where it's common to want to configure first, then set your composables. The configure method should be something more like:

    fun <TRule : ScreenshotRule<T>> configure(configureRule: TestifyConfiguration.() -> Unit): TRule {
        configureRule.invoke(configuration)
        return this as TRule
    }
    
    Feedback Library Testify 2.0 Extension Architecture 
    opened by DanielJette 0
  • Issue-95: Add resource wrapping to ComposableTestActivity

    Issue-95: Add resource wrapping to ComposableTestActivity

    What does this change accomplish?

    Resolves #95

    ComposableTestActivity now supports resource wrapping. This means that Testify can configure the font scale and locale for tests. Compose screenshot tests will now respect the locale and fontScale configuration parameters. Usage:

    rule
        .setCompose {
            Text("Example")
        }
        .configure {
            this.locale = Locale.FRANCE
            this.fontScale = 2.0f
        }
    
    opened by DanielJette 0
  • Font scale configuration for Compose tests

    Font scale configuration for Compose tests

    Is your feature request related to a problem? Please describe. Absolutely love that we can configure font scales by creating our own test activity that implements TestifyResourcesOverride. Would be great to update ComposableTestActivity to implement TestifyResourcesOverride so that font scale or locale can be configured out-of-the-box for Jetpack Compose tests.

    This feedback relates to:

    • [x] The Kotlin library
    • [ ] The Gradle plugin
    • [ ] The IntelliJ Platform plugin
    • [ ] The sample code
    • [ ] The documentation

    Describe the solution you'd like Update ComposableTestActivity to implement TestifyResourcesOverride so that font scale or locale can be configured for Jetpack Compose tests.

    Describe alternatives you've considered Alternatively we could update ComposableScreenshotRule to optionally accept a custom activity, much like ScreenshotRule.

    Additional context N/A

    Feedback Library Testify 2.0 
    opened by ryansama 1
Releases(2.0.0-alpha01)
  • 2.0.0-alpha01(Jun 6, 2022)

    What does this change accomplish?

    :warning: Major breaking changes.

    This version is provided as an easier migration path to the Testify 2.0 libraries. 2.0.0-alpha01 is identical functionality to 1.2.0-alpha01 but all classes have been updated to use the new dev.testify namespace.

    If you update all of your code to reference dev.testify instead of com.shopify.testify you will be better positioned to adopt the new Testify 2.0 API.

    Source code(tar.gz)
    Source code(zip)
Owner
ndtp
ndtp
Selenium locators for Java/Kotlin that resemble the Testing Library (testing-library.com).

Selenium Testing Library Testing Library selectors available as Selenium locators for Kotlin/Java. Why? When I use Selenium, I don't want to depend on

Luís Soares 5 Dec 15, 2022
Snapshot/Screenshot test example project

Snapshot Snapshot/Screenshot test example code using Showkase (https://github.com/airbnb/Showkase) Paparazzi (https://github.com/cashapp/paparazzi) Te

Anders Ullnæss 3 Nov 25, 2022
Android UI Testing

User scenario testing for Android Robotium is an Android test automation framework that has full support for native and hybrid applications. Robotium

null 2.8k Dec 14, 2022
A set of AssertJ helpers geared toward testing Android.

AssertJ Android A set of AssertJ assertions geared toward testing Android. Deprecated The support libraries and play services are developing at a rate

Square 1.6k Jan 3, 2023
Android Unit Testing Framework

Robolectric is the industry-standard unit testing framework for Android. With Robolectric, your tests run in a simulated Android environment inside a

Robolectric 5.6k Jan 3, 2023
Android UI Testing

User scenario testing for Android Robotium is an Android test automation framework that has full support for native and hybrid applications. Robotium

null 2.7k Apr 8, 2021
A sample repo describing best practices for snapshot testing on Android

Road to effective snapshot testing A sample repo describing best practices for snapshot testing on Android. This includes for now: Parameterized Tests

Sergio Sastre Flórez 86 Jan 1, 2023
A programmer-oriented testing framework for Java.

JUnit 4 JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. For more infor

JUnit 8.4k Jan 9, 2023
A programmer-oriented testing framework for Java.

JUnit 4 JUnit is a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. For more infor

JUnit 8.4k Dec 28, 2022
Turbine is a small testing library for kotlinx.coroutines Flow.

A small testing library for kotlinx.coroutines Flow

Cash App 1.8k Jan 5, 2023
Fixtures for Kotlin providing generated values for unit testing

A tool to generate well-defined, but essentially random, input following the idea of constrained non-determinism.

Appmattus Limited 191 Dec 21, 2022
Morsa: Jetpack Compose UI Testing Framework

Morsa: Jetpack Compose UI Testing Framework Test library to ease UI testing with Jetpack Compose Purpose This library aims to add some useful wrappers

HyperDevs 10 Dec 3, 2022
Lovely Systems Database Testing

Lovely DB Testing This repository provides opinionated testing helpers for database testing used at Lovely Systems. License This plugin is made availa

Lovely Systems GmbH 1 Feb 23, 2022
Project for testing intern candidate simple level

RickAndMorty-TestTask Тестовый проект 'Гайд по мультфильму Рик и Морти' для практикантов начального и продвинутого уровня. Структура проекта Структура

null 0 Nov 18, 2021
Very simple Morse API text translator. Mainly to do some testing with jitpack, API development etc.

Very simple Morse text translator API. Far from finish or even being reliable. Use for single sentence. Mainly to test github dependency for Android

Piotr Dymala 0 Dec 30, 2021
Snapshot Testing framework for Kotlin.

KotlinSnapshot Snapshot Testing framework for Kotlin. What is this? Snapshot testing is an assertion strategy based on the comparision of the instance

Pedro Gómez 157 Nov 13, 2022
A set of TestRules and ActivityScenarios to facilitate UI Testing under given configurations: FontSizes, Locales

AndroidUiTestingUtils A set of TestRules, ActivityScenarios and utils to facilit

Sergio Sastre Flórez 122 Dec 23, 2022
Android library that allows you to run your acceptance tests written in Gherkin in your Android instrumentation tests.

Green Coffee Green Coffee is a library that allows you to run your acceptance tests written in Gherkin in your Android instrumentation tests using the

Mauricio Togneri 227 Nov 21, 2022
null 866 Dec 27, 2022