This message was deleted.
# android
s
This message was deleted.
n
wehre is that time going? is it downloading the robolectric jars?
j
No, I think whatever setup robolectric has to do when it first launches is causing that slowdown
At least, I’m not aware of it downloading any jars
https://github.com/robolectric/robolectric/issues/5847 is one of the tickets on their issue tracker about it
d
First, can you try and update to 4.4 at least? It seems that they had an issue where they were reading the binary zips were taking too long - https://github.com/robolectric/robolectric/issues/5118 We recently went from 4.3 -> 4.7.3 and had our worst offender (testing N -> R) have single test class go from 1m 42s -> 42s.
j
We are using 4.7.3
d
ah, my bad. Went off of the version in the links and assumed, incorrectly, it was your filing.
j
Oh yeah sorry. Those bugs are definitely just things I have found in my research.
Not sure if anyone would know this, but would a build service be able to force all these tests to run in the same classloader so that whatever initialization work is done for robolectric tests can be forced to only happen once?
e
I think Gradle can't do anything about this. RobolectricTestRunner does try to re-use sandboxes between test methods, if they have the same configuration, but it's scoped to a single test class only, that's just how JUnit4 runners work. you'd have to write a RobolectricSuite to share between test classes.