Closed tek closed 8 years ago
Hi, Sorry for late response, and thanks for your contribution. This looks interesting, initially I thought that this would call for completely separate project, but you managed to reuse so much code that it makes sense now :) I never really used specs2, so will need to play a bit with that.
Could you provide example tests using this, maybe the one with FragmentManager
problem?
sure! might take a while.
So, I finally got around to revisiting this and concluded that the fragment problem lies elsewhere, so you could just merge this. Check out this project for a demonstration of two identical nested-fragment test cases in specs2 and scalatest: https://github.com/tek/robo_specs2
The thing is it doesn't work for me. Did you try to run tests in robotest? Even DatabaseRoboSpec
fails with your changes.
I don't really know Specs2, but don't think this integration would be as simple as you made it.
Test with nested-fragments is very simple, please try to add more things, something that actually makes use of shadows.
I'll check again; I'm sure the tests worked, I probably screwed something up before pushing.
So, I modified the database spec for specs2, and it works, although not in sequence. As I stated initially, I hadn't managed to implement the teardown, so obviously this cannot be merged, sorry about my confusion ;) Anyway, if you remove the individual examples selectively, you can see that it works.
I'm going to have another go at the teardown now.
ok, I've managed to get the specs working. I'd say that the specs2 philosophy generally leans towards isolating individual runs into classes, not methods, and rather treats methods as separate testable aspects of a single run; therefore, I would consider this an adequate implementation.
The current method uses a var
to store the runner containing the outside universe, and overwrites the robolectric instance's runner from outside on initialization, allowing it to be used for teardown in the afterAll
hook.
On my machine, the specs run successfully in succession now. Would you give it a try?
Your code works now.
I'd say that the specs2 philosophy generally leans towards isolating individual runs into classes, not methods, and rather treats methods as separate testable aspects of a single run; therefore, I would consider this an adequate implementation.
From simple examples on Sepcs2 website this doesn't seem to be true. Usually tests have several methods, and this will fail with your implementation.
I tried something like that:
class SampleRoboSpecification extends RobolectricSpecification {
override def beforeAll(): Unit = ()
def is = s2"""
this is my specification
where example 1 must be true $e1
where example 2 must be true $e2
"""
def e1 = {
val bmp = BitmapFactory.decodeStream(new ByteArrayInputStream(Array.empty)) // just to use some shadow
1 must_== 1
}
def e2 = 2 must_== 2
}
And it crashes.
I don't really want to have limited support for Specs2, this will cause to much maintenance problems in future. Either we can support it completely, or not at all. Maybe it's better to have that as a separate library, you could update https://github.com/jbrechtel/robospecs to latest Robolectric instead?
Your example passes on my machine, are you sure you pulled the latest changes?
I didn't mean that specs shouldn't be able to contain multiple examples; the "run" I was referring to, which should represent an individual class, was meant to reflect a startup-shutdown cycle of shadows, which seems to me to be an acceptable limitation. You can still have multiple items tested in one go, you just can't shut down android in between.
Anyway, if this is unsatisfactory for you, I'm perfectly fine with creating a separate project.
No idea why it doesn't work for me. To be honest, I would actually prefer that to be a separate project. Don't think many ppl will need both test libraries in single project, and don't feel comfortable maintaining specs2 related code. Feel free to re-use whatever you can from here, I may also us some of the refactoring that you did here.
ok, sure. It would be useful to just inherit the nonspecific code from robotest; until you're gonna get to that, I'll just copy it over.
hey there, this is a tentative solution for specs2; due to the convoluted nature of the execution model, this proves pretty difficult – consequently, there is no teardown at the end of a spec. The only solution I came up with for that was an override of the whole sbt test framework with a lot of duplicate code, which is pretty much undesirable. Anyway, this works so far. I don't know if you'll want this mixed in one project, so feel free to restructure.
I encountered a problem I couldn't resolve, maybe you can provide some insight here: with specs2, nested fragments are handled incorrectly. I.e. it seems that at some point, the regular fragment manager is delegated to instead of the child fragment manager, resulting in an invalid state error in
FragmentManager.executePendingTransactions
. It's quite curious that it wouldn't happen in an identical test using the scalatest variant, so I assume it's an initialization problem. Do you think it's possible that the wrong android version is used at some point? the nested fragment problem is more serious in earlier versions iirc, I had that problem before in Robolectric and solved it somehow, but don't remember how.