Mockito behavior with Specs_2.9.0-1-1.6.8

[Thomas Sant'ana]

I just tried to move my project from Scala 2.8.1 to Scala 2.9.0.1 and several tests that worked on specs_2.8.1-1.6.7 stopped passing.

 Is there some significant change on how the mocks are setup between 1.6.7 and 1.6.8?

I had failures on things like:

"on construction start and register" in {
      there was one(anObserverActor).start() then
              one(anObserverActor).registerWithTracker(mTracker)
    }

Giving me:
org.specs.runner.SpecAssertionFailedError$$anon$1: The mock was not called as expected:
Missing method call for verify(mock) here:
-> at org.specs.mock.CalledMatchers$class.org$specs$mock$CalledMatchers$$verify(Mockito.scala:207)

Example of correct verification:
    verify(mock).doSomething()

The next mock simply hangs for ever (could be actor problems).

And also calls that look correct are failing.

Now my major question is what my best course of action?

a) stay at my version (which blocks scala 2.9.0.1 and all the updates on specs2, such as 1.5 etc)
b) migrate all the specs (or at least the failing ones) to org.specs2.mutable and hope for the best
c) Wait for 1.6.9 (opening proper tickets for the errors)

I can try to cook up some reduced examples, but only is (c) is the course to follow.

Thomas

[etorreborre]

Hi Thomas,

Maybe option b) is not as hard as you think and would get you started to a full migration (that would also be the easiest for me :-)).

Otherwise just open some tickets and I will fix the issues on 1.6.9. Please try to minimize them so that they're not dependent on your own code.

Thanks,

Eric.

[Thomas Sant'ana]

On Sat, Jul 9, 2011 at 8:26 PM, etorreborre <etorr...@gmail.com> wrote:

Hi Thomas,

Maybe option b) is not as hard as you think and would get you started to a full migration (that would also be the easiest for me :-)).

I had a feeling that was the most likely outcome. I'll give a try once I push a release of my project.
 

Otherwise just open some tickets and I will fix the issues on 1.6.9. Please try to minimize them so that they're not dependent on your own code.

If migration does not work I'll try to create some cases...

Some of the code that is causing problem is kind of on it's way to decommissioning  so this is bad for me too. And I'm going on the same path as Specs2 (more functional). But it's a pain to move...



Thomas

[Bill Venners]

Hi Thomas, Eric,

On Jul 9, 4:32 pm, "Thomas Sant'ana" <maill...@gmail.com> wrote:

One other option if it turns out to be too painful to migrate to
specs2 is to look into migrating to ScalaTest WordSpecs and/or
FreeSpecs. Judging from Eric's lengthy migration doc, depending upon
what you have done in specs it might be easier to migrate your
existing tests to ScalaTest than specs2.

One big difference between ScalaTest and specs is that is not obvious
from a feature comparison is I work very hard not to break my users'
code. I will certainly never do any kind of massive breaking such as
the specs2 rewrite, and I'm also very attentive to avoiding even minor
breakages between regular releases. Upgrading to a new version of
ScalaTest generally requires a recompile and that's all. So its a much
smoother ride in that sense. If that's important to you, I think it is
worth taking another look at ScalaTest.

Features you used and liked in specs1, like the Mockito DSL or its
matchers, you can (as far as I know) mix right into a ScalaTest style
trait as well, thereby potentially giving you the best of both worlds
and a smoother upgrade path. Eric and I both work very hard to keep
Scala folks testing productively, and I think people tend to think
they have to pick one framework or the other when you can actually use
both.

Bill

[etorreborre]

Hi Thomas (and others),

What Bill says is true, and I give him credit for working really hard to keep the best compatibility between ScalaTest versions (to a point rarely seen in many other libraries). Also the specs/specs2 transition is a  huge break (for all the reasons I explained in the User Guide) and you shouldn't expect too many variations in between specs2 versions.

 

That being said I want to emphasize that I will fix issues for specs users so that no migration is necessary. So if you prefer to stay with specs1, I'll fix the issues that you're facing.

Otherwise, as Bill wrote, it is certainly possible to mix and match the 2 libraries (ScalaTest and specs2) to a certain point and in that case I would advise to use the specs2 traits which are more flexible in terms of mixing with other libraries.

Cheers,

Eric.