These are chat archives for etorreborre/specs2

4th
Jul 2017
Eric Torreborre
@etorreborre
Jul 04 2017 06:35
Bjørn Madsen
@aeons
Jul 04 2017 06:35
awesome!
Eric Torreborre
@etorreborre
Jul 04 2017 07:43
Thank you I will try to have a look at that today
Bjørn Madsen
@aeons
Jul 04 2017 07:43
great, thanks
Eric Torreborre
@etorreborre
Jul 04 2017 12:02
@aeons the trouble with your example is that we compare exception which indeed have a different stack trace. The test however passes with
     // exact same exception
      val failure: ExampleFailure = ExampleFailure(42)

      val et: ExampleResult[Int] = EitherT(Task(success(13 * 37)))
      et.flatMap(_ => EitherT(Task(Left(failure): Either[ExampleFailure, Int]))) must returnLeft(failure)
Bjørn Madsen
@aeons
Jul 04 2017 14:40
okay, that makes sense
but since the failure is actually a case class, can we not do value based equality?
Eric Torreborre
@etorreborre
Jul 04 2017 14:45
It's also an exception, if you can add an interface to that exception you might be able to do like this. I think this is the same issue
Bjørn Madsen
@aeons
Jul 04 2017 14:49
hmm, there is an interface, but the top most trait extends runtimeexception
the workaround with comparing reference equality is fine for this test though
Eric Torreborre
@etorreborre
Jul 04 2017 14:50
I think you can still try to cast to this interface, this should work and default to the default equality
Bjørn Madsen
@aeons
Jul 04 2017 15:00
sealed trait MessageFailure extends RuntimeException
sealed trait DecodeFailure extends MessageFailure
sealed trait MessageBodyFailure extends DecodeFailure
sealed case class MalformedMessageBodyFailure(details: String, override val cause: Option[Throwable] = None) extends MessageBodyFailure
    "flatMapR with failure" in {
      val failure: DecodeFailure = MalformedMessageBodyFailure("bummer")
      DecodeResult.success(req).flatMap { r =>
        EntityDecoder.text
          .flatMapR(_ => DecodeResult.failure[String](MalformedMessageBodyFailure("bummer")))
          .decode(r, strict = false)
      } must returnLeft(failure)
that’s the actual code
and it still fails with that, but maybe I’m misunderstanding you
Eric Torreborre
@etorreborre
Jul 04 2017 15:26
/@all I've just released specs2 3.9.2: http://bit.ly/SPECS2_3_9_2
@aeons right, the Diffable[Throwable] must still be picked up in that case. The case in issue 562 is indeed different because the exception is declared as extends Throwable with VaultModel
Bjørn Madsen
@aeons
Jul 04 2017 15:28
ah, right
Eric Torreborre
@etorreborre
Jul 04 2017 15:31
So the only work-arounds I know for this are to use a val or to "deactivate" the throwable Diffable instance by shadowing the implicit method name: val exceptionDiffable = 1 in your spec
but that's really ugly (and not future proof)
Bjørn Madsen
@aeons
Jul 04 2017 15:32
ok