These are chat archives for etorreborre/specs2

1st
Mar 2018
Bert Poller
@bpoller
Mar 01 2018 10:51

Hi Eric, I would like to specify the timeFactor in a test as in

class ATestSpec extends Specification with TeamMoodTestApplication {

  def is(implicit ee: ExecutionEnv) = args.execute(timeFactor = 1)  ^ {
...
}
}

though it compiles there's something wrong in my syntax as the result says empty test suite

Could you please give me a little hint ? Thanks :smile:
Eric Torreborre
@etorreborre
Mar 01 2018 12:10
Can you please tell me which version you are using? I'll try to have a look this afternoon
Bert Poller
@bpoller
Mar 01 2018 12:35
Its version 3.8.9. After further investigation I rephrase my problem statement with the following complete code snipped :
package services

import org.specs2.concurrent.ExecutionEnv
import org.specs2.mutable.Specification

import scala.concurrent.Future


class ATestSpec(implicit ee: ExecutionEnv) extends Specification {

  override def is = args(xonly = true) ^ {

    "TeamService" should {
      "count the team size" in {
        val result = Future(1)
        result must beEqualTo(1).await
      }
    }
  }
}
I would like to inject command line arguments into my test. However as soon as I use the def is = syntax regardless of whether I use an args statement or not, test execution works but test results show: "Empty test suite."
Thank you @etorreborre for having a look into it
Eric Torreborre
@etorreborre
Mar 01 2018 13:06
Can you try 4.0.3? Also how do you run your tests, IntelliJ? Did you try with sbt only?
Also arguments in a mutable spec can be invoked directly:
class ATestSpec(implicit ee: ExecutionEnv) extends mutable.Specification {

  xonly

  "TeamService" should {
    "count the team size" in {
      val result = Future(1)
      result must beEqualTo(1).await
    }
  }
}
In mutable specs you can't use def is because this method is automatically populated when you write statements like "count the team size" in .... This add a new 'Specification fragment' to a private local variable. When executing the spec, all the collected fragments are being used to implement the def is method. This is all the beauty of having a DSL relying on mutation :-)
Bert Poller
@bpoller
Mar 01 2018 13:13
Ok Eric, you last phrase was a bit too challenging for me, the noob. But your trick with the xonly did it ! Thank you.
One last question instead of the xonly, I could change the timeFactor by simply plugging args.execute(timeFactor = 25) ?
Eric Torreborre
@etorreborre
Mar 01 2018 13:14
yes that's supposed to work
Bert Poller
@bpoller
Mar 01 2018 13:14
ok that's great ! I'll give it a try :thumbsup:
This did the job. Done! Thank you so much! :clap:
Eric Torreborre
@etorreborre
Mar 01 2018 13:18
The last phrase is worth thinking about. The code you put in a mutable.Specification is declared inside the body of a class. This is cool because you can write those statements without having to related them to any attribute or method. ButSo when you load the class, this code is executed right away. And this code is the whole spec definition! So if we want to control how things are executed we need to store this code in a mutable variable, hence the name mutable.Specification. That's why, in order to be able to implement such a DSL, we need mutability and this complicates a bunch of things internally.
Good, glad to know everything's working for you :-)