Espresso semi-parallel test execution fails on static objects [37082857]

Fixed

Bug

[AOSP] duplicate

[AOSP] assigned

Status Update

No update yet.

Description

v....@gmail.com

created issue #1

Feb 22, 2016 10:15AM

Library used: com.android.support.test.espresso:espresso-core:2.2.1
Version used: 2.2.1

What steps will reproduce the problem?
1. Have atleast 3 tests
2. Log messages in activity onCreate and onDestroy
3. Observe onCreate -> onDestroy messages not going in order (onCreate -> onDestroy, onCreate -> onDestroy, onCreate -> onDestroy)

How are you running your tests (via Android Studio, Gradle, adb, etc.)?
Android Studio 1.5.1

What is the expected output? What do you see instead?
Log messages going sequentially (onCreate -> onDestroy, onCreate -> onDestroy, onCreate -> onDestroy)

I am trying to use espresso and junit4. The problem seems to be that I have code that is statically initialized in activity.onCreate and deinitialized in activity.onDestroy to prevent leaks, etc.

Now when I run espresso, the tests seem to run in "parallel". I added log class to activity onCreate and onDestroy.

What I am seeing is

onCreate = example.package.MainActivity@ABC
onCreate = example.package.MainActivity@JKL
onDestroy = example.package.MainActivity@ABC
onCreate = example.package.MainActivity@XYZ
onDestroy = example.package.MainActivity@JKL
onDestroy = example.package.MainActivity@XYZ

**and ofcourse it fails on NPE in third test because the second test's onDestroy ran after third's onCreate (which null-ed out the static code)**

Is this behaviour normal? Can I force espresso to teardown activity instance first and only then start a new one? Thanks!

Comments

sl...@google.com <sl...@google.com> #2Feb 29, 2016 09:11PM

this would be nice but given Compose and all other priorities, we are not planning to make any big investments in data binding (support KSP is a very big task).

v....@gmail.com <v....@gmail.com> #3Feb 29, 2016 09:23PM

Makes sense. And is there any way to trigger data binding without kapt plugin, assuming there are no custom binding adapters in given module?

ai...@gmail.com <ai...@gmail.com> #4Apr 4, 2016 05:49AM

unfortunately no. data binding still needs to be able to read your code and annotation processing is the only API that allows us to do it :(

nk...@google.com <nk...@google.com> Apr 4, 2016 06:23PM

Assigned to nk...@google.com.

ar...@gmail.com <ar...@gmail.com> #5Jul 4, 2016 02:46PM

It's a very disappointing decision for many projects who heavily depend on data binding, which will never be able to get rid of all bindings code and especially rewrite all UI to Compose.

It means that bindings are essentially deprecated

nk...@google.com <nk...@google.com> #6Jul 6, 2016 08:51PM

It does not mean data binding is deprecated unless KAPT is deprecated (if that happens, we would need to support KSP).Unfortunately, moving data binding to KSP is a large order so it makes more sense to keep focusing on KAPT than rewrite data binding.

We might re-consider this in the future based on KSP becoming stable, Compose adoption and KAPT stability but it is very unlikely to happen.

be...@gmail.com <be...@gmail.com> #8Aug 10, 2016 02:21AM

Unfortunately this is still a NO for 2022 planning due to reasons mentioned in #2.

fr...@gmail.com <fr...@gmail.com> #9Feb 3, 2017 09:50AM

kapt seems no longer adding new feature

kapt is in maintenance mode. We are keeping it up-to-date with recent Kotlin and Java releases but have no plans to implement new features. Please use the Kotlin Symbol Processing API (KSP) for annotation processing. See the list of libraries supported by KSP.

https://kotlinlang.org/docs/kapt.html

So this mean databinding will also deprecated or will be support KSP?

xa...@gmail.com <xa...@gmail.com> #10Jun 19, 2017 01:10PM

Databinding is in maintenance mode as well.
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.

vi...@gmail.com <vi...@gmail.com> #11Jun 20, 2017 11:35AM

We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.

I have been waited this answer in several years.

Because it is an important basis to convince co-workers and for determining the technology stack of an app.

nk...@google.com <nk...@google.com> #12Jun 26, 2017 07:39PM

Marked as fixed.

Databinding is in maintenance mode as well.

We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.

A bit of a tangent here, but what about ViewBinding? Will that one stay going strong or will it fade along with DataBinding?

to...@gmail.com <to...@gmail.com> #13Jul 20, 2017 09:27PM

ViewBinding is only a build tool and does not run an annotation processor, hence it is not impacted by KAPT / KSP.

So if you are using Views, ViewBinding will keep working.
It is the same for Data Binding as well though. The main difference is that if KAPT stops working, DataBinding will stop working whereas ViewBinding will keep working. Hopefully, any such situation will be far enough that no-one will care and everyone will be using Compose :)

su...@gmail.com <su...@gmail.com> #14Jul 26, 2017 05:01AM

Kotlin K2 compiler doesn't support kapt anymore, which means the data-binding library can be dead soon.

https://github.com/JetBrains/kotlin/blob/master/plugins/kapt3/kapt3-compiler/src/org/jetbrains/kotlin/kapt3/Kapt3Plugin.kt#L71-L76

to...@gmail.com <to...@gmail.com> #15Jul 26, 2017 04:33PM

Here is the tracking bug on YouTrack: https://youtrack.jetbrains.com/issue/KT-51982/K2-Support-Kapt

jc...@gmail.com <jc...@gmail.com> #16Apr 17, 2018 06:31AM

#14 Kapt will be supported on K2, there are no plans to stop supporting it in Kotlin

nk...@google.com <nk...@google.com> #17Apr 17, 2018 07:28PM

gooooogle, gradle and kotlin are a perfect match ☺️

nk...@google.com <nk...@google.com> #18Apr 17, 2018 07:28PM

deleted

da...@gmail.com <da...@gmail.com> #19May 23, 2018 10:22AM

Any other updates about this bug? I'm still issuing it with:
- androidTestImplementation 'com.android.support.test:runner:1.0.2'
- androidTestImplementation 'com.android.support.test:rules:1.0.2'
- androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
Tests always passes individually.
Running the suite instead, they have an unpredictable behavior: sometimes they passes, sometimes do not.

gu...@gmail.com <gu...@gmail.com> #20Jul 9, 2018 05:31PM

For some reason with databinding and static class I cannot debug code in ViewModel at every 2 test. Individually everything is just fine. espresso 3.0.2

gu...@gmail.com <gu...@gmail.com> #21Jul 10, 2018 11:35AM

This is works like this (everything is without package). In my View which is Activity I call onStart() and onPause() of ViewModel. In xml I have button with enabled set to MutableLiveData<Boolean> property in ViewModel. I write in Kotlin

//This is button enabled field update, each time when this MutableLiveData<Boolean> is called it prints this.toString()
PersonalViewModel@52cb180
PersonalViewModel@52cb180
PersonalViewModel@52cb180
PersonalViewModel@52cb180
PersonalViewModel@52cb180
PersonalViewModel@52cb180

//Second test start onStart() of ViewModel
START: PersonalViewModel@43321e0

PersonalViewModel@43321e0 //Calls button MutableLiveData<Boolean> for enabled property only ONCE

//Second test onPause() of ViewModel
PAUSE: PersonalViewModel@43321e0

//Third test start onStart() of ViewModel
START: PersonalViewModel@dc72c50
PersonalViewModel@dc72c50 //Calls button MutableLiveData<Boolean> for enabled property only ONCE
PAUSE: PersonalViewModel@dc72c50

When the second test starts it seems like it calls MutableLiveData<Boolean> property only once for button and then it fails to bind or something, because button is not updating anymore. Individually all tests work.