Use specs2 rather than the ancient specs.
Among other things allows us to port to 2.10, since specs is obviously not published for 2.10.
Not finished yet --- currently pushed common, actor, json*, util. Locally have webkit, db, mapper too.
Anyone that wants to work on another subproject comment on this ticket first to prevent duplicate work.
Initial experiment with Specs2
update core/common tests to use specs2
Changes to build files
json, json-scalaz, json-ext
Remove MailerSpec hack, now that testMode checking is fixed in Props
github is showing the dates really weirdly btw...
Since I'm doing this for the most part subproject by subproject, anyone who wants to review this can begin doing so, but do it by commit rather than by the overall diff, so you can pick up where you left off after future commits.
Fix Props.mode calculatation to work with specs2 concurrent test running
Note: this is needed by the last two commits (MailerSpec and
lift-mongo (tests pass now)
Now up for review!
I think it's fine but, could we not use success instead of 1 must_== 1 ?
1 must_== 1
IIRC no, because it needed a MatchResult, while success is a Result.
What might be better is:
invokeMethod(null, "", "length").getClass must_== classOf[Failure[_]]
(or if specs2 has a built in way to say that).
At the moment I'm pretty swamped though so I'd rather not bother.
done with this commit
does the success here mean that if
actor => actor must_== Empty
is not Empty, the test case will pass anyway?
I pulled this branch locally and verified that having the success is just to make specs2 happy, if there is a failure in the previous line, we get a failed test.
The explicit "forExample" statements were added because there was a conflict with Squeryl's implicit conversion for the "in" operator. I'd just make sure that this is run against all supported Scala versions before we commit to it. It's possible that it was only an older version of Scala that was affected, but it was the previous maintainer who ran into the issue and I'm not sure what triggered it.
Right now master builds for
Seq("2.9.2", "2.9.1-1", "2.9.1", "2.9.0-1", "2.9.0")
but, there is no specs for version 2.9.0-1 so I think for 2.5, we will only be building 2.9.2 , 2.9.1 (and 2.10 if all goes well I imagine) , I tested locally and 2.9.1 and 2.9.2 pass the tests just fine
Done reviewing all the commits, they all look good, just one thing, could we include a "BoxMatcher" trait, so that users of Lift would not have to do things like boxedVallue.isDefinied must_== true ?
boxedVallue.isDefinied must_== true
Thanks for all the work with the migration!
and when you rebase this into master, I guess it would be time to also drop 2.9.0-1 from build.sbt (You got a few +1 on the lift committer list and I'm pretty sure I also posted the question on the regular list and got a few votes, but I can't find that post now :(