Issue #242 - Add support to write Kaspresso-like tests that run on the JVM with Robolectric #243

sergio-sastre · 2021-05-19T20:15:18Z

No description provided.

… that can run on the JVM and on a device/emulator

CLAassistant · 2021-05-19T20:15:23Z

All committers have signed the CLA.

sergio-sastre · 2021-05-22T14:39:10Z

@matzuk

RuslanMingaliev · 2021-05-22T18:52:53Z

Wow, great job! Thank you for contribution.
We'll take a closer look in the coming days

matzuk · 2021-05-24T10:56:24Z

Hi @sergio-sastre!
Thanks a lot for your job! We really appreciate such kind of help!
We got the main idea and concerns about using Robolectric in Kaspresso. Also, your code has highlighted all necessary changes.

So, my thoughts:

I think we have to be able to configure such things using the only Kaspresso.Builder. Yep, it's a little bit challenge to create a suitable and not confusing config =)
Classes duplication is not a very good solution. We try to avoid such an approach.
We have two almost ready PR that will affect the project seriously. That's why I suggest 1. to wait these PR 2. after, apply concepts from your PR to support Robolectric in the separate third PR
If you have some time limits to support Robolectric then let us know. We are ready to introduce Robolectric support as soon as possible for you.

sergio-sastre · 2021-05-25T11:38:02Z

@matzuk
I completely agree with all the points.
Just let me know whether you want me to help add Robolectric compatibility through the Kaspresso.Builder (and what to consider while doing it) once those PRs are merged.

Regarding point 4, no real time limits on my side.

sergio-sastre · 2021-07-14T21:00:48Z

Hi @sergio-sastre!
Thanks a lot for your job! We really appreciate such kind of help!
We got the main idea and concerns about using Robolectric in Kaspresso. Also, your code has highlighted all necessary changes.

So, my thoughts:

I think we have to be able to configure such things using the only Kaspresso.Builder. Yep, it's a little bit challenge to create a suitable and not confusing config =)

Classes duplication is not a very good solution. We try to avoid such an approach.

We have two almost ready PR that will affect the project seriously. That's why I suggest 1. to wait these PR 2. after, apply concepts from your PR to support Robolectric in the separate third PR

If you have some time limits to support Robolectric then let us know. We are ready to introduce Robolectric support as soon as possible for you.

Hi there!
I have good news!
I found an approach to get it working without the code duplication and making it configurable on the Kaspresso.Builder.
Before I proceed to a complete solution and some code cleaning, I just want to ask for your opinion on my approach. Any suggestions are very welcome.

First of all, enabling tests to also run on the JVM would look like this:

class SharedTest : TestCase(Kaspresso.Builder.simple(sharedTest = true)){}

Coming back to the solution, the main problem was the hard dependency to Automator in Kaspresso, namely

private val uiDevice = UiDevice.getInstance(instrumentation)

as well the one in the Kaspresso constructor:

data class Kaspresso(
...
internal val device: Device,
...
)

I solved it by first removing UiDevice from Kaspresso.Builder, and making Device optional in the constructor (and the corresponding changes it implies). Then I apply a factory pattern to return the proper config, so UiDevice is only used by KautomatorOnDeviceConfig, like this

object KautomatorConfigResolver {

    fun build(sharedTest: Boolean): KautomatorConfig =
        when (sharedTest) {
            true -> KautomatorOnJVMConfig()
            false -> KautomatorOnDeviceConfig()
        }
}

class KautomatorOnDeviceConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer =
        AdbServerImpl(LogLevel.WARN, libLogger)

    override fun getPermissions(libLogger: UiTestLogger): Permissions =
        PermissionsImpl(libLogger, getUiDevice())

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network =
        NetworkImpl(getInstrumentation().targetContext, adbServer, libLogger)
   ...
    private fun getUiDevice() : UiDevice = UiDevice.getInstance(getInstrumentation())
}

and in Robolectric those methods return empty implementations of the objects (they are not supported by Robolectric anyway, since are UIAutomator-dependent)

class KautomatorOnJVMConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer = object: AdbServer{}

    override fun getPermissions(libLogger: UiTestLogger): Permissions = object: Permissions{}

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network = object: Network{}
     ...
}

and in the Kaspresso.Builder variable initialisation...

@Suppress("detekt.ComplexMethod")
private fun postInitVariables(sharedTest: Boolean) {
       val kautomatorConfig = KautomatorConfigResolver.build(sharedTest)
       if (!::libLogger.isInitialized) libLogger = UiTestLoggerImpl(DEFAULT_LIB_LOGGER_TAG)
       ...
       
       if (!::adbServer.isInitialized) adbServer = kautomatorConfig.getAdbServer(libLogger)
       if (!::network.isInitialized) network = kautomatorConfig.getNetwork(adbServer, libLogger)
       ...
}

Let me know your thoughts on this ;)

matzuk · 2021-07-19T14:55:50Z

Hi @sergio-sastre!
Thank you for your fixed version!
Please, give us time to check and observe your code.
With best regards!

matzuk · 2021-07-27T18:10:24Z

@sergio-sastre Hi!
Sorry, there's a lot of work this week. Promise to review and answer all questions on the closest weekend =)

matzuk · 2021-08-01T09:40:27Z

Hi @sergio-sastre!
Thanks a lot for your job! We really appreciate such kind of help!
We got the main idea and concerns about using Robolectric in Kaspresso. Also, your code has highlighted all necessary changes.
So, my thoughts:

I think we have to be able to configure such things using the only Kaspresso.Builder. Yep, it's a little bit challenge to create a suitable and not confusing config =)

Classes duplication is not a very good solution. We try to avoid such an approach.

We have two almost ready PR that will affect the project seriously. That's why I suggest 1. to wait these PR 2. after, apply concepts from your PR to support Robolectric in the separate third PR

If you have some time limits to support Robolectric then let us know. We are ready to introduce Robolectric support as soon as possible for you.

Hi there!
I have good news!
I found an approach to get it working without the code duplication and making it configurable on the Kaspresso.Builder.
Before I proceed to a complete solution and some code cleaning, I just want to ask for your opinion on my approach. Any suggestions are very welcome.

First of all, enabling tests to also run on the JVM would look like this:
class SharedTest : TestCase(Kaspresso.Builder.simple(sharedTest = true)){}
Coming back to the solution, the main problem was the hard dependency to Automator in Kaspresso, namely
private val uiDevice = UiDevice.getInstance(instrumentation)
as well the one in the Kaspresso constructor:
data class Kaspresso(
...
internal val device: Device,
...
)
I solved it by first removing UiDevice from Kaspresso.Builder, and making Device optional in the constructor (and the corresponding changes it implies). Then I apply a factory pattern to return the proper config, so UiDevice is only used by KautomatorOnDeviceConfig, like this
object KautomatorConfigResolver {

    fun build(sharedTest: Boolean): KautomatorConfig =
        when (sharedTest) {
            true -> KautomatorOnJVMConfig()
            false -> KautomatorOnDeviceConfig()
        }
}
class KautomatorOnDeviceConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer =
        AdbServerImpl(LogLevel.WARN, libLogger)

    override fun getPermissions(libLogger: UiTestLogger): Permissions =
        PermissionsImpl(libLogger, getUiDevice())

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network =
        NetworkImpl(getInstrumentation().targetContext, adbServer, libLogger)
   ...
    private fun getUiDevice() : UiDevice = UiDevice.getInstance(getInstrumentation())
}
and in Robolectric those methods return empty implementations of the objects (they are not supported by Robolectric anyway, since are UIAutomator-dependent)
class KautomatorOnJVMConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer = object: AdbServer{}

    override fun getPermissions(libLogger: UiTestLogger): Permissions = object: Permissions{}

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network = object: Network{}
     ...
}
and in the Kaspresso.Builder variable initialisation...
@Suppress("detekt.ComplexMethod")
private fun postInitVariables(sharedTest: Boolean) {
       val kautomatorConfig = KautomatorConfigResolver.build(sharedTest)
       if (!::libLogger.isInitialized) libLogger = UiTestLoggerImpl(DEFAULT_LIB_LOGGER_TAG)
       ...
       
       if (!::adbServer.isInitialized) adbServer = kautomatorConfig.getAdbServer(libLogger)
       if (!::network.isInitialized) network = kautomatorConfig.getNetwork(adbServer, libLogger)
       ...
}
Let me know your thoughts on this ;)

Hi @sergio-sastre!
I've reviewed your solution. So, now it looks better =) But, the big number of !! and ? really confuses me. Also, I see some kind of duplication code in KautomatorConfig, anyway.
If we have problems with UI Automator classes then maybe there is a sense to wrap only these classes? It will interfaces with two implementations: first - call UI Automator, second - throw Exceptions (with all needed additional information, sure). Yep, throwing exceptions in different places is not a very appropriate way. On the other hand, Kaspresso declares using UI Automator as a tool helping in a lot of cases, and UI tests are not associated with JVM. That's why if you want to run your tests on JVM only then be ready to change your tests. Wrapping of UI Automator classes simplifies an introduction of Robolectric support into Kaspresso. But, the common disadvantage of our attempts is how to warm a user and how to highlight code where UI Automator is using. Or do we make a user responsible for such experiments with Robolectric?
@RuslanMingaliev @eakurnikov your opinion?

sergio-sastre · 2021-08-04T19:19:40Z

Hi @sergio-sastre!
Thanks a lot for your job! We really appreciate such kind of help!
We got the main idea and concerns about using Robolectric in Kaspresso. Also, your code has highlighted all necessary changes.
So, my thoughts:

I think we have to be able to configure such things using the only Kaspresso.Builder. Yep, it's a little bit challenge to create a suitable and not confusing config =)

Classes duplication is not a very good solution. We try to avoid such an approach.

We have two almost ready PR that will affect the project seriously. That's why I suggest 1. to wait these PR 2. after, apply concepts from your PR to support Robolectric in the separate third PR

If you have some time limits to support Robolectric then let us know. We are ready to introduce Robolectric support as soon as possible for you.

Hi there!
I have good news!
I found an approach to get it working without the code duplication and making it configurable on the Kaspresso.Builder.
Before I proceed to a complete solution and some code cleaning, I just want to ask for your opinion on my approach. Any suggestions are very welcome.
First of all, enabling tests to also run on the JVM would look like this:
class SharedTest : TestCase(Kaspresso.Builder.simple(sharedTest = true)){}
Coming back to the solution, the main problem was the hard dependency to Automator in Kaspresso, namely
private val uiDevice = UiDevice.getInstance(instrumentation)
as well the one in the Kaspresso constructor:
data class Kaspresso(
...
internal val device: Device,
...
)
I solved it by first removing UiDevice from Kaspresso.Builder, and making Device optional in the constructor (and the corresponding changes it implies). Then I apply a factory pattern to return the proper config, so UiDevice is only used by KautomatorOnDeviceConfig, like this
object KautomatorConfigResolver {

    fun build(sharedTest: Boolean): KautomatorConfig =
        when (sharedTest) {
            true -> KautomatorOnJVMConfig()
            false -> KautomatorOnDeviceConfig()
        }
}
class KautomatorOnDeviceConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer =
        AdbServerImpl(LogLevel.WARN, libLogger)

    override fun getPermissions(libLogger: UiTestLogger): Permissions =
        PermissionsImpl(libLogger, getUiDevice())

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network =
        NetworkImpl(getInstrumentation().targetContext, adbServer, libLogger)
   ...
    private fun getUiDevice() : UiDevice = UiDevice.getInstance(getInstrumentation())
}
and in Robolectric those methods return empty implementations of the objects (they are not supported by Robolectric anyway, since are UIAutomator-dependent)
class KautomatorOnJVMConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer = object: AdbServer{}

    override fun getPermissions(libLogger: UiTestLogger): Permissions = object: Permissions{}

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network = object: Network{}
     ...
}
and in the Kaspresso.Builder variable initialisation...
@Suppress("detekt.ComplexMethod")
private fun postInitVariables(sharedTest: Boolean) {
       val kautomatorConfig = KautomatorConfigResolver.build(sharedTest)
       if (!::libLogger.isInitialized) libLogger = UiTestLoggerImpl(DEFAULT_LIB_LOGGER_TAG)
       ...
       
       if (!::adbServer.isInitialized) adbServer = kautomatorConfig.getAdbServer(libLogger)
       if (!::network.isInitialized) network = kautomatorConfig.getNetwork(adbServer, libLogger)
       ...
}
Let me know your thoughts on this ;)
Hi @sergio-sastre!
I've reviewed your solution. So, now it looks better =) But, the big number of !! and ? really confuses me. Also, I see some kind of duplication code in KautomatorConfig, anyway.
If we have problems with UI Automator classes then maybe there is a sense to wrap only these classes? It will interfaces with two implementations: first - call UI Automator, second - throw Exceptions (with all needed additional information, sure). Yep, throwing exceptions in different places is not a very appropriate way. On the other hand, Kaspresso declares using UI Automator as a tool helping in a lot of cases, and UI tests are not associated with JVM. That's why if you want to run your tests on JVM only then be ready to change your tests. Wrapping of UI Automator classes simplifies an introduction of Robolectric support into Kaspresso. But, the common disadvantage of our attempts is how to warm a user and how to highlight code where UI Automator is using. Or do we make a user responsible for such experiments with Robolectric?
@RuslanMingaliev @eakurnikov your opinion?

Hi @matzuk!
Thanks for your feedback, it is very valuable!
I personally believe the user should be responsible for such experiments with Robolectric, but we warned about the reason of the failing test when running on the JVM because of UiAutomator.

Wrapping UiDevice (the direct UiAutomator class that causes the problem) in an interface would solve the problem and help catch and throw the desired exceptions to warn the user about the incompatibility of the running test with Robolectric. I believe that would be a pretty nice solution, and seems feasible.
I have to assess how much work it is indeed, but hope to adjust the PR in the following week.

Regarding the code duplication in KautomatorConfig, what do you mean exactly? I am open to any suggestion to improve it :)

matzuk · 2021-08-09T04:43:59Z

Hi @sergio-sastre!
Thanks a lot for your job! We really appreciate such kind of help!
We got the main idea and concerns about using Robolectric in Kaspresso. Also, your code has highlighted all necessary changes.
So, my thoughts:

I think we have to be able to configure such things using the only Kaspresso.Builder. Yep, it's a little bit challenge to create a suitable and not confusing config =)

Classes duplication is not a very good solution. We try to avoid such an approach.

We have two almost ready PR that will affect the project seriously. That's why I suggest 1. to wait these PR 2. after, apply concepts from your PR to support Robolectric in the separate third PR

If you have some time limits to support Robolectric then let us know. We are ready to introduce Robolectric support as soon as possible for you.

Hi there!
I have good news!
I found an approach to get it working without the code duplication and making it configurable on the Kaspresso.Builder.
Before I proceed to a complete solution and some code cleaning, I just want to ask for your opinion on my approach. Any suggestions are very welcome.
First of all, enabling tests to also run on the JVM would look like this:
class SharedTest : TestCase(Kaspresso.Builder.simple(sharedTest = true)){}
Coming back to the solution, the main problem was the hard dependency to Automator in Kaspresso, namely
private val uiDevice = UiDevice.getInstance(instrumentation)
as well the one in the Kaspresso constructor:
data class Kaspresso(
...
internal val device: Device,
...
)
I solved it by first removing UiDevice from Kaspresso.Builder, and making Device optional in the constructor (and the corresponding changes it implies). Then I apply a factory pattern to return the proper config, so UiDevice is only used by KautomatorOnDeviceConfig, like this
object KautomatorConfigResolver {

    fun build(sharedTest: Boolean): KautomatorConfig =
        when (sharedTest) {
            true -> KautomatorOnJVMConfig()
            false -> KautomatorOnDeviceConfig()
        }
}
class KautomatorOnDeviceConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer =
        AdbServerImpl(LogLevel.WARN, libLogger)

    override fun getPermissions(libLogger: UiTestLogger): Permissions =
        PermissionsImpl(libLogger, getUiDevice())

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network =
        NetworkImpl(getInstrumentation().targetContext, adbServer, libLogger)
   ...
    private fun getUiDevice() : UiDevice = UiDevice.getInstance(getInstrumentation())
}
and in Robolectric those methods return empty implementations of the objects (they are not supported by Robolectric anyway, since are UIAutomator-dependent)
class KautomatorOnJVMConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer = object: AdbServer{}

    override fun getPermissions(libLogger: UiTestLogger): Permissions = object: Permissions{}

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network = object: Network{}
     ...
}
and in the Kaspresso.Builder variable initialisation...
@Suppress("detekt.ComplexMethod")
private fun postInitVariables(sharedTest: Boolean) {
       val kautomatorConfig = KautomatorConfigResolver.build(sharedTest)
       if (!::libLogger.isInitialized) libLogger = UiTestLoggerImpl(DEFAULT_LIB_LOGGER_TAG)
       ...
       
       if (!::adbServer.isInitialized) adbServer = kautomatorConfig.getAdbServer(libLogger)
       if (!::network.isInitialized) network = kautomatorConfig.getNetwork(adbServer, libLogger)
       ...
}
Let me know your thoughts on this ;)
Hi @sergio-sastre!
I've reviewed your solution. So, now it looks better =) But, the big number of !! and ? really confuses me. Also, I see some kind of duplication code in KautomatorConfig, anyway.
If we have problems with UI Automator classes then maybe there is a sense to wrap only these classes? It will interfaces with two implementations: first - call UI Automator, second - throw Exceptions (with all needed additional information, sure). Yep, throwing exceptions in different places is not a very appropriate way. On the other hand, Kaspresso declares using UI Automator as a tool helping in a lot of cases, and UI tests are not associated with JVM. That's why if you want to run your tests on JVM only then be ready to change your tests. Wrapping of UI Automator classes simplifies an introduction of Robolectric support into Kaspresso. But, the common disadvantage of our attempts is how to warm a user and how to highlight code where UI Automator is using. Or do we make a user responsible for such experiments with Robolectric?
@RuslanMingaliev @eakurnikov your opinion?
Hi @matzuk!
Thanks for your feedback, it is very valuable!
I personally believe the user should be responsible for such experiments with Robolectric, but we warned about the reason of the failing test when running on the JVM because of UiAutomator.

Wrapping UiDevice (the direct UiAutomator class that causes the problem) in an interface would solve the problem and help catch and throw the desired exceptions to warn the user about the incompatibility of the running test with Robolectric. I believe that would be a pretty nice solution, and seems feasible.
I have to assess how much work it is indeed, but hope to adjust the PR in the following week.

Regarding the code duplication in KautomatorConfig, what do you mean exactly? I am open to any suggestion to improve it :)

@sergi

Hi @sergio-sastre!
Thanks a lot for your job! We really appreciate such kind of help!
We got the main idea and concerns about using Robolectric in Kaspresso. Also, your code has highlighted all necessary changes.
So, my thoughts:

I think we have to be able to configure such things using the only Kaspresso.Builder. Yep, it's a little bit challenge to create a suitable and not confusing config =)

Classes duplication is not a very good solution. We try to avoid such an approach.

We have two almost ready PR that will affect the project seriously. That's why I suggest 1. to wait these PR 2. after, apply concepts from your PR to support Robolectric in the separate third PR

If you have some time limits to support Robolectric then let us know. We are ready to introduce Robolectric support as soon as possible for you.

Hi there!
I have good news!
I found an approach to get it working without the code duplication and making it configurable on the Kaspresso.Builder.
Before I proceed to a complete solution and some code cleaning, I just want to ask for your opinion on my approach. Any suggestions are very welcome.
First of all, enabling tests to also run on the JVM would look like this:
class SharedTest : TestCase(Kaspresso.Builder.simple(sharedTest = true)){}
Coming back to the solution, the main problem was the hard dependency to Automator in Kaspresso, namely
private val uiDevice = UiDevice.getInstance(instrumentation)
as well the one in the Kaspresso constructor:
data class Kaspresso(
...
internal val device: Device,
...
)
I solved it by first removing UiDevice from Kaspresso.Builder, and making Device optional in the constructor (and the corresponding changes it implies). Then I apply a factory pattern to return the proper config, so UiDevice is only used by KautomatorOnDeviceConfig, like this
object KautomatorConfigResolver {

    fun build(sharedTest: Boolean): KautomatorConfig =
        when (sharedTest) {
            true -> KautomatorOnJVMConfig()
            false -> KautomatorOnDeviceConfig()
        }
}
class KautomatorOnDeviceConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer =
        AdbServerImpl(LogLevel.WARN, libLogger)

    override fun getPermissions(libLogger: UiTestLogger): Permissions =
        PermissionsImpl(libLogger, getUiDevice())

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network =
        NetworkImpl(getInstrumentation().targetContext, adbServer, libLogger)
   ...
    private fun getUiDevice() : UiDevice = UiDevice.getInstance(getInstrumentation())
}
and in Robolectric those methods return empty implementations of the objects (they are not supported by Robolectric anyway, since are UIAutomator-dependent)
class KautomatorOnJVMConfig : KautomatorConfig {

    override fun getAdbServer(libLogger: UiTestLogger): AdbServer = object: AdbServer{}

    override fun getPermissions(libLogger: UiTestLogger): Permissions = object: Permissions{}

    override fun getNetwork(adbServer: AdbServer, libLogger: UiTestLogger): Network = object: Network{}
     ...
}
and in the Kaspresso.Builder variable initialisation...
@Suppress("detekt.ComplexMethod")
private fun postInitVariables(sharedTest: Boolean) {
       val kautomatorConfig = KautomatorConfigResolver.build(sharedTest)
       if (!::libLogger.isInitialized) libLogger = UiTestLoggerImpl(DEFAULT_LIB_LOGGER_TAG)
       ...
       
       if (!::adbServer.isInitialized) adbServer = kautomatorConfig.getAdbServer(libLogger)
       if (!::network.isInitialized) network = kautomatorConfig.getNetwork(adbServer, libLogger)
       ...
}
Let me know your thoughts on this ;)
Hi @sergio-sastre!
I've reviewed your solution. So, now it looks better =) But, the big number of !! and ? really confuses me. Also, I see some kind of duplication code in KautomatorConfig, anyway.
If we have problems with UI Automator classes then maybe there is a sense to wrap only these classes? It will interfaces with two implementations: first - call UI Automator, second - throw Exceptions (with all needed additional information, sure). Yep, throwing exceptions in different places is not a very appropriate way. On the other hand, Kaspresso declares using UI Automator as a tool helping in a lot of cases, and UI tests are not associated with JVM. That's why if you want to run your tests on JVM only then be ready to change your tests. Wrapping of UI Automator classes simplifies an introduction of Robolectric support into Kaspresso. But, the common disadvantage of our attempts is how to warm a user and how to highlight code where UI Automator is using. Or do we make a user responsible for such experiments with Robolectric?
@RuslanMingaliev @eakurnikov your opinion?
Hi @matzuk!
Thanks for your feedback, it is very valuable!
I personally believe the user should be responsible for such experiments with Robolectric, but we warned about the reason of the failing test when running on the JVM because of UiAutomator.

Wrapping UiDevice (the direct UiAutomator class that causes the problem) in an interface would solve the problem and help catch and throw the desired exceptions to warn the user about the incompatibility of the running test with Robolectric. I believe that would be a pretty nice solution, and seems feasible.
I have to assess how much work it is indeed, but hope to adjust the PR in the following week.

Regarding the code duplication in KautomatorConfig, what do you mean exactly? I am open to any suggestion to improve it :)

Hi @sergio-sastre!

About KautomatorConfig. After wrapping of UI Automator classes, KautomatorConfig will be unnecessary, I think.

sergio-sastre · 2021-08-18T15:02:23Z

Hi @matzuk!
Sorry for not updating this yet, I got other stuff that has priority first. I promise to try to include the proposed changes before the end of the month!

matzuk · 2021-10-12T03:18:16Z

merged in #286

sergio-sastre added 6 commits May 5, 2021 22:24

Add KaspressoNitrogen necessary classes

fdaec53

Uncomment Espresso failure handler in KaspressoNitrogen

614c4ff

Add roboelectric dependencies + configure sharedTest folder for tests…

7750db7

… that can run on the JVM and on a device/emulator

Add Activity to use as Test Sample for Nitrogen shared tests

02b5ddc

Add working sharedTest

ab76cae

Modify wifi to include Kaspresso-Nitrogen

b3464cb

sergio-sastre marked this pull request as draft May 22, 2021 14:31

sergio-sastre marked this pull request as ready for review May 22, 2021 14:32

sergio-sastre marked this pull request as draft May 22, 2021 14:32

sergio-sastre marked this pull request as ready for review May 22, 2021 14:45

RuslanMingaliev assigned RuslanMingaliev and matzuk May 22, 2021

RuslanMingaliev requested review from RuslanMingaliev, matzuk and eakurnikov May 22, 2021 18:53

RuslanMingaliev assigned eakurnikov May 22, 2021

matzuk linked an issue May 24, 2021 that may be closed by this pull request

Feature request: Make Kaspresso robolectric-compatible (Project Nitrogen) #242

Closed

sergio-sastre mentioned this pull request Jul 17, 2021

#issue242 add robolectric support #267

Merged

matzuk closed this Oct 12, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue #242 - Add support to write Kaspresso-like tests that run on the JVM with Robolectric #243

Issue #242 - Add support to write Kaspresso-like tests that run on the JVM with Robolectric #243

sergio-sastre commented May 19, 2021

CLAassistant commented May 19, 2021 •

edited

Loading

sergio-sastre commented May 22, 2021

RuslanMingaliev commented May 22, 2021

matzuk commented May 24, 2021

sergio-sastre commented May 25, 2021

sergio-sastre commented Jul 14, 2021 •

edited

Loading

matzuk commented Jul 19, 2021

matzuk commented Jul 27, 2021

matzuk commented Aug 1, 2021

sergio-sastre commented Aug 4, 2021 •

edited

Loading

matzuk commented Aug 9, 2021

sergio-sastre commented Aug 18, 2021

matzuk commented Oct 12, 2021

Issue #242 - Add support to write Kaspresso-like tests that run on the JVM with Robolectric #243

Issue #242 - Add support to write Kaspresso-like tests that run on the JVM with Robolectric #243

Conversation

sergio-sastre commented May 19, 2021

CLAassistant commented May 19, 2021 • edited Loading

sergio-sastre commented May 22, 2021

RuslanMingaliev commented May 22, 2021

matzuk commented May 24, 2021

sergio-sastre commented May 25, 2021

sergio-sastre commented Jul 14, 2021 • edited Loading

matzuk commented Jul 19, 2021

matzuk commented Jul 27, 2021

matzuk commented Aug 1, 2021

sergio-sastre commented Aug 4, 2021 • edited Loading

matzuk commented Aug 9, 2021

sergio-sastre commented Aug 18, 2021

matzuk commented Oct 12, 2021

CLAassistant commented May 19, 2021 •

edited

Loading

sergio-sastre commented Jul 14, 2021 •

edited

Loading

sergio-sastre commented Aug 4, 2021 •

edited

Loading