Skip to content
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

[distage-testkit] Nesting of should verbs #1812

Open
ncreep opened this issue Nov 2, 2022 · 2 comments
Open

[distage-testkit] Nesting of should verbs #1812

ncreep opened this issue Nov 2, 2022 · 2 comments
Labels
complex A hard problem

Comments

@ncreep
Copy link

ncreep commented Nov 2, 2022

Hi,

It seems that distage-testkit doesn't adopt vanilla Scalatest's behavior when nesting should/must/can verbs and omits some information when nesting.

For example, consider the following test:

"a" should {
  "b" can {
    "c" in {
      1 shouldBe 1
    }

    "d" in {
      2 shouldBe 2
    }
  }
}

When running this in plain ScalaTest the output would be:

[info] a
[info]   should b
[info]   - can c
[info]   - can d

With the distage-testkit the output will be:

[info] - b can c
[info] - b can d

Note how the information about a is completely missing, and everything is flattened losing the nesting of the code.

Is this behavior intentional?
Will it be complicated to reproduce ScalaTest's behavior? If it's not too big of a change, I can try to tackle it on my own and open a pull request.

Thanks

@pshirshov
Copy link
Member

Will it be complicated to reproduce ScalaTest's behavior?

Well, it's definitely doable, though scalatest dsl isn't a trivial thing, so no wonder we didn't pass it through perfectly.

Don't forget that we do not preserve scalatest hierarchies because of the parallel runs and reporter protocol limitations. But we can certainly preserve the whole descriptions. There will be no tree, but reports would look like

[info] - a should b can c
[info] - a should b can d

I can try to tackle it on my own and open a pull request.

Please do.

@ncreep
Copy link
Author

ncreep commented Nov 6, 2022

Thanks for the quick response.
Not losing information might be good enough, I guess.

I might try to tackle this at some point. Will let you know if I stumble upon any issues doing that (might take some time though).

@pshirshov pshirshov added the complex A hard problem label Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complex A hard problem
Projects
None yet
Development

No branches or pull requests

2 participants