New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Examples in unit spec don't seem to nest properly with "in" #140

Closed
asflierl opened this Issue Mar 15, 2013 · 6 comments

Comments

Projects
None yet
2 participants
@asflierl
Contributor

asflierl commented Mar 15, 2013

Hi Eric,

running the unit specbelow with specs2 version 1.14, I'd expect all examples to fail, i.e. 8 failures. Surprisingly, only 6 examples fail. The 2 subexamples that are nested more than 2 levels by using the "in" method never seem to be executed. The same level of nesting works fine if I use ">>" instead.

Here's the self-contained example:

package fnord

import org.specs2.mutable._

class Subexamples extends SpecificationWithJUnit {
  "Subexamples nested with 'in'" should {
    "nest once" in { 
      false must beTrue
    }

    "nest twice" in {
      "sub1" in {
        false must beTrue
      }
    }

    "nest three times" in {
      "sub2" in {
        "subsub2" in {
          false must beTrue
        }
      }
    }

    "nest four times" in {
      "sub3" in {
        "subsub3" in {
          "subsubsub3" in {
            false must beTrue
          }
        }
      }
    }
  }

  "Subexamples nested with '>>'" should {
    "nest once" >> { 
      false must beTrue
    }

    "nest twice" >> {
      "sub1" >> {
        false must beTrue
      }
    }

    "nest three times" >> {
      "sub2" >> {
        "subsub2" >> {
          false must beTrue
        }
      }
    }

    "nest four times" >> {
      "sub3" >> {
        "subsub3" >> {
          "subsubsub3" >> {
            false must beTrue
          }
        }
      }
    }
  }
}
@etorreborre

This comment has been minimized.

Show comment
Hide comment
@etorreborre

etorreborre Mar 15, 2013

Owner

This is not a bug but a result of trying to do too much with the same method names. Here's an explanation of what happens. I'm starting to wonder if the convenience of having in(block: T): Unit is worth it.

Owner

etorreborre commented Mar 15, 2013

This is not a bug but a result of trying to do too much with the same method names. Here's an explanation of what happens. I'm starting to wonder if the convenience of having in(block: T): Unit is worth it.

@asflierl

This comment has been minimized.

Show comment
Hide comment
@asflierl

asflierl Mar 15, 2013

Contributor

Hmm. This is unfortunate. With all due respect, in my opinion, there's nothing worse than rather obscure issues like this one. Especially if all a user can do about this is remember to use ">>" for deeper nesting.

Users will just not use deeper nesting instead and the resulting specs will be worse - which is even more unfortunate. I stumbled upon this weird behaviour during a code retreat when I was trying to show a colleague that you can neatly arrange things in a nice hierarchial way. So this issue was a showstopper and completely destroyed my argument. ;-)

Is there a way to import the second use of "in" away somehow? (a renaming import) ... or something that could go in a parent trait? Although I'd rather have you reconsider your choice... but I'll respect your call that this is not a bug.

Contributor

asflierl commented Mar 15, 2013

Hmm. This is unfortunate. With all due respect, in my opinion, there's nothing worse than rather obscure issues like this one. Especially if all a user can do about this is remember to use ">>" for deeper nesting.

Users will just not use deeper nesting instead and the resulting specs will be worse - which is even more unfortunate. I stumbled upon this weird behaviour during a code retreat when I was trying to show a colleague that you can neatly arrange things in a nice hierarchial way. So this issue was a showstopper and completely destroyed my argument. ;-)

Is there a way to import the second use of "in" away somehow? (a renaming import) ... or something that could go in a parent trait? Although I'd rather have you reconsider your choice... but I'll respect your call that this is not a bug.

@etorreborre etorreborre reopened this Mar 16, 2013

@etorreborre

This comment has been minimized.

Show comment
Hide comment
@etorreborre

etorreborre Mar 16, 2013

Owner

You're right, I'm going to reconsider this. Probably by requiring the user to explicitly import the additional behaviour that in(block: T): Unit allows.

Owner

etorreborre commented Mar 16, 2013

You're right, I'm going to reconsider this. Probably by requiring the user to explicitly import the additional behaviour that in(block: T): Unit allows.

@asflierl

This comment has been minimized.

Show comment
Hide comment
@asflierl

asflierl Mar 16, 2013

Contributor

Thank you very much!

Contributor

asflierl commented Mar 16, 2013

Thank you very much!

@etorreborre

This comment has been minimized.

Show comment
Hide comment
@etorreborre

etorreborre Mar 17, 2013

Owner

Hi Andreas, starting with 1.15-SNAPSHOT it will not be possible to have a block returning Unit in >> or in. Instead, you have to explicitly state what you want:

"create several examples" >> {
  examplesBlock((1 to 5) foreach (i => "example"+i >> ok))
}
"create several expectations" >> {
  // unit creates a result from a side-effecting block (i.e. possibly throwing exceptions)
  Result.unit((1 to 5) foreach (i => i === i))
}

I think this is for the best, thanks for raising the issue.

Owner

etorreborre commented Mar 17, 2013

Hi Andreas, starting with 1.15-SNAPSHOT it will not be possible to have a block returning Unit in >> or in. Instead, you have to explicitly state what you want:

"create several examples" >> {
  examplesBlock((1 to 5) foreach (i => "example"+i >> ok))
}
"create several expectations" >> {
  // unit creates a result from a side-effecting block (i.e. possibly throwing exceptions)
  Result.unit((1 to 5) foreach (i => i === i))
}

I think this is for the best, thanks for raising the issue.

@asflierl

This comment has been minimized.

Show comment
Hide comment
@asflierl

asflierl Mar 18, 2013

Contributor

This is great! Thank you so much. Examples resulting in Unit were the cause of many suboptimal specs anyway. :)

Contributor

asflierl commented Mar 18, 2013

This is great! Thank you so much. Examples resulting in Unit were the cause of many suboptimal specs anyway. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment