If Scope extends MustExpectations - it causes failing tests to look like running and **passing**

[maximn]

Here's a sample code -

package com.sample

import org.specs2.matcher.MustExpectations
import org.specs2.mutable.SpecificationWithJUnit
import org.specs2.specification.Scope


class BadTest extends SpecificationWithJUnit {

  trait ctx extends Scope with MustExpectations {}

  "Wrong statement" should {
    "be failed by a test" in new ctx {
      true must be_===(false)
    }
  }
}


//trait ctx extends Scope with Matchers with MustExpectations {
//  def someThingThatUsesMust(x: AnyRef) = x must beNull
//}

As you can see in the screenshot - IntelliJ shows the test as running and green.

[etorreborre]

Yes, it needs to extend MustThrownExpectations for exceptions to be thrown and caught outside of the Scope trait.

[etorreborre]

Also, in this specific example you shouldn't need to create MustExpectations because MustThrownExpectations is already mixed in org.specs2.mutable.SpecificationWithJUnit and allows to create expectations already. So I guess that you are creating the ctx trait outside of a specific Specification to be able to reuse it, right?

[maximn]

Maybe I shouldn't use MustExpectations, but if I do, I expect to get an error somewhere.
Yes, I use it outside. Actually in my case my context extends a trait that extends MustExpectations but I wanted to provide the most simple example.

[etorreborre]

There are 2 traits offering the same API but having different implementations: MustExpectations and MustThrownExpectations. As the name indicates MustThrownExpectations must be used where exceptions are expected for control flow. Typically in this situation where code is being placed in the body of a trait (the ctx trait); if no exception is thrown there is no way to get notified of failures.

It would be better to have a compilation error when MustExpectations is being mixed-in with Scope but I don't know how to do that.

[etorreborre]

I have added 2 methods on Scope and MustExpectations to detect this issue at compile-time. I'm not sure this is the best way to do it but that should work for now.

[etorreborre]

My fix is incorrect. I need a bit more time to find something else. In any case I would like a fix for this issue to happen at compile time rather than runtime (I thank you for your PR though :-)).