These are chat archives for etorreborre/specs2

30th
Mar 2017
Joao Azevedo
@jcazevedo
Mar 30 2017 11:20
Is it possible to add examples to an existent block created with should? I'm extending a mutable spec and I'd like to add more examples to the existent block, rather than creating a new one.
Eric Torreborre
@etorreborre
Mar 30 2017 14:40
@jtjeferreira I know about the notes site being down. I am now publishing the notes on github. I am currently working on a fix for the issue you reported. Hopefully I can publish something next week
@jtjeferreira there's no decision to drop scalaz 7.1, it just takes a bit of time to publish every time so I tend to do it on demand
@jcazevedo I don't think there's an easy way to do that
G. Richard Bellamy
@rbellamy
Mar 30 2017 15:08
I've asked this question before, and am still unclear of the "best practices" way of handling the answer - so I apologize for repeating what is probably simple question with a simple answer that I'm just too dense to get...
Eric Torreborre
@etorreborre
Mar 30 2017 15:08
please ask!
G. Richard Bellamy
@rbellamy
Mar 30 2017 15:09
I work with Scaldi, and would like the implicit Injector to be available at the Specification level. I can put the implicit injector on the Example scope, and that's probably the most "correct way", e.g.
trait InjectorForEach extends Specification with Mockito with ForEach[Injector] {
  this: MocksCreation =>
  def module: MutableInjectorAggregation

  override protected def foreach[R](f: (Injector) => R)(implicit ev: AsResult[R]): Result = {
    AsResult(f(module))
  }
}
however, there are times that it really doesn't make sense to have a module-per-example, and instead I want a module-per-specification
btw, the trait above allows me to do things like:
...
def mocksModule = new Module {
  bind[SomeMockery] to mock[SomeMockery]
}
override val module = mocksModule :: Helpers.allModules
which supports a high-level module that has all the globally necessary cruft, and then allows me to mock whatever I need within the context of the example - or depending on the specification, I can add another trait in the type hierarchy that carries a set of shared mocks
G. Richard Bellamy
@rbellamy
Mar 30 2017 15:14
I've looked at the BeforeSpec, AfterSpec and others of that ilk, but am unclear how they would actually place the injector on the implicit scope of the Spec
s/how they would place/how I would use them to place
does my question make sense @etorreborre ?
Eric Torreborre
@etorreborre
Mar 30 2017 15:16
The ForEach way seems to be ok to get the injector for each example. At the specification level I don't understand why a simple val with the Injector doesn't work?
class MySpec extends Specification {
  val injector: Injector = ???
}
G. Richard Bellamy
@rbellamy
Mar 30 2017 15:17
that's actually how I've been doing it...
so, a bit more information, and probably a correction in my language?
I'm porting some tests written by others....
class MySpec extends Specification {
  "This test" should {
    "do something really correct" in {
    }
  }
  "This other test" should {
    "do something really incorrect" in {
    }
  }
}
so it looks something like that
what I want is:
class MySpec extends Specification {
  "This test" should { implicit inj: Injector =>
    "do something really correct" in {
    }
  }
  "This other test" should { implicit inj: Injector =>
    "do something really incorrect" in {
    }
  }
}
so, now that I think about it, it's not REALLY an "injector per specification"
Eric Torreborre
@etorreborre
Mar 30 2017 15:20
and where would the different injectors come from?
G. Richard Bellamy
@rbellamy
Mar 30 2017 15:21
each injector would be a newly instantiated module, just like the InjectorForEach
Eric Torreborre
@etorreborre
Mar 30 2017 15:21

why not

```
class MySpec extends Specification {
  "This test" should {
    implicit val  inj: Injector = injector1
    "do something really correct" in {
    }
  }
  "This other test" should { 
implicit val inj: Injector = injector2
    "do something really incorrect" in {
    }
  }
}

```

BTW do the injectors have to be implicit?
G. Richard Bellamy
@rbellamy
Mar 30 2017 15:22
@etorreborre that would certainly work
and NO, injectors don't have to be implicit, not technically
but if you use the implicit scope as a pattern, then yeah... they do
well, actually, that's not even true - NO, they don't HAVE to be implicit
(I'm still getting my scala learn on)
Eric Torreborre
@etorreborre
Mar 30 2017 15:24

I think that sometimes the easiest thing is just to use vals and defs

// create a fresh injector
// and use inj everywhere you need it
val inj = createInjector

This doesn't require much ceremony

G. Richard Bellamy
@rbellamy
Mar 30 2017 15:25
oh, a function value
yeah, that makes perfect sense
Andreas Flierl
@asflierl
Mar 30 2017 15:34
Hi. Given the rather minimal (mutable) Spec class MeepSpec extends mutable.Specification { "a" >> ( "b" >> ( "c" >> ( "d" >> ok ) ) ) }, in the generated test report XML, I would expect the example name to be "a::b::c::d" but it actually is "c::b::a::d". Should I open a bug? :D
works OK for nesting once (a >> b) but starts messing up the order for more (a >> b >> c ...)
Eric Torreborre
@etorreborre
Mar 30 2017 15:44
it looks like a bug to me
and that should be too hard to fix
Andreas Flierl
@asflierl
Mar 30 2017 15:50
ok thanks. filed #561
Eric Torreborre
@etorreborre
Mar 30 2017 15:52
thanks I'm on it
Eric Torreborre
@etorreborre
Mar 30 2017 16:25
@asflierl the fix is available in 3.8.9-20170330160759-0665464
Jonas Michel
@jonasrmichel
Mar 30 2017 16:49

Perhaps and often-asked question, but I'm failing to find the answer...

How do I execute all tests in my project via the command line? As far as I can tell specs2.run expects a single class name.

I'd really like to just do something like...
$ java -cp ... specs2.run org.project.test.*

Jonas Michel
@jonasrmichel
Mar 30 2017 17:25
Ah, looks like I can use the specs2.files Runner. Interestingly, I have to provide the fully qualified path of the files runner on the command line...
$ java -cp ... org.specs2.runner.files
G. Richard Bellamy
@rbellamy
Mar 30 2017 19:03
I've got another seemingly easy question that's baffling me. Say I have a Future[CdcStats] where:
case class CdcStats(nCreates: Int, nDeletes: Int)
how do I test the stats.nCreates?
I'm having a hellofa time figuring out how to unwrap the attribute of the future using an ExecutionEnv
I'm aware I can Await.result(stats, Duration.Inf).nCreates must_===50
or something like that...
G. Richard Bellamy
@rbellamy
Mar 30 2017 22:50
okay, I'm just full of questions today!
Anybody have an example of multiple examples using the same datatable?