These are chat archives for etorreborre/specs2

28th
Sep 2015
tony kerz
@tony-kerz
Sep 28 2015 03:29

in my case, i actually wanted to provide an initialized variable isolated per test, so i arrived at:

import org.junit.runner.RunWith
import org.specs2.mock.Mockito
import org.specs2.mutable.SpecificationWithJUnit
import org.specs2.runner.JUnitRunner
import org.specs2.specification.Scope

class ScratchSpec extends SpecificationWithJUnit with Mockito {
  trait Context extends Scope {
    val uuid = java.util.UUID.randomUUID.toString
    println(s"context: uuid=$uuid")
  }

  "scratch" should {
    "be true" in new Context {
      println(s"1: uuid=$uuid")
      (!false == true) must beTrue
    }
    "be true too" in new Context {
      println(s"2: uuid=$uuid")
      (!false == true) must beTrue
    }
  }
}

seems to work, but feel free to critique

Eric Torreborre
@etorreborre
Sep 28 2015 03:45
Hi Tony, for boolean assertions you can either: return a boolean value or use must beTrue. However returning a boolean value doesn’t work where side-effects are expected like using Scope so if you use mutable specs you should better use must beTrue
Your example with BeforeEach works for me so many you have a buggy version of specs2. Which one is it?
Then you can use a scope to isolate your variables but you can also use the isolated argument
class ScratchSpec extends SpecificationWithJUnit with Mockito {
  isolated

  val uuid = java.util.UUID.randomUUID.toString

  "scratch" should {
    "be true" in {
      println(s"1: uuid=$uuid")
      false must beTrue
    }
    "be true too" in {
      println(s"2: uuid=$uuid")
      false must beTrue
    }
  }
}
btw if you have upvoted my previous answer on StackOverflow you might as well approve it and set a green check on it :-)
tony kerz
@tony-kerz
Sep 28 2015 11:54
thanks for all the tips @etorreborre!
(1) i think i'll just use must beTrue all the time for consistency and Scope compliance
(2) of course i should have provided the version i was running: 2_2.11.0-RC3:2.3.10(now that you mention it, i did try to use a later version and maven/m2e couldn't resolve specs2-core_2.11:3.6.4-20150927082714-7cac887 for some reason)
(3) love the isolated syntax, terse and works well
(4) doh, stack-overflow-challenged apparently, u def get the green-check for that ;)
Eric Torreborre
@etorreborre
Sep 28 2015 11:56
@tony-kerz cool, glad I could help!
tony kerz
@tony-kerz
Sep 28 2015 12:20

so w.r.t. versions, i tried again this morning to update and was able to get the most recent version(s) from maven (last time it was probably that annoying maven dont-retry-for-a-certain-time thing). in the latest version features are split across a family of jars, so i got core, mock, junit, etc. and i'm getting a couple of errors that i don't understand. can you spot either of these issues?:

(1) org.mockito.stubbing.Stubber does not take parameters on:

    doNothing().when(mesosDriver).start()

https://github.com/mesos/chronos/blob/2.4.0/src/test/scala/org/apache/mesos/chronos/scheduler/jobs/JobSchedulerElectionSpec.scala#L122

(2) type mismatch; found : org.specs2.specification.core.Fragment required: org.specs2.matcher.Matcher[String] on:

    "Tests that dependent jobs run when parents are updated" in {

https://github.com/mesos/chronos/blob/2.4.0/src/test/scala/org/apache/mesos/chronos/scheduler/jobs/JobSchedulerIntegrationTest.scala#L416

Eric Torreborre
@etorreborre
Sep 28 2015 22:39
@tony-kerz I don’t see anything obviously wrong here. Could you prepare a branch where I can reproduce the compilation errors? (and give me the compile command, is it just mvn compile?)