Sorry, bug in the documentation. Those curly braces need to be parens.
This will work:
import org.scalatest.Suite
import org.scalatest.Suites
class StepsSuite extends Suites(
new Step1Suite,
new Step2Suite,
new Step3Suite,
new Step4Suite,
new Step5Suite
)
class Step1Suite extends Suite
class Step2Suite extends Suite
class Step3Suite extends Suite
class Step4Suite extends Suite
class Step5Suite extends Suite
The reason is that Scala only lets you pass one arg between curly
braces. To pass more than one arg separate by commas, you always need
to use parens. I'll update the scaladoc.
Thanks.
Bill
> --
> You received this message because you are subscribed to the Google
> Groups "scalatest-users" group.
> To post to this group, send email to scalate...@googlegroups.com
> To unsubscribe from this group, send email to
> scalatest-use...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/scalatest-users?hl=en
> ScalaTest itself, and documentation, is available here:
> http://www.artima.com/scalatest
--
Bill Venners
Artima, Inc.
http://www.artima.com
Not off the shelf at the moment other than using TestNGSuite or
overriding one of the lifecycle methods. Dependent tests is something
I wanted to wait on until I had some real use cases in front of me.
Can you let me know exactly what it is you'd like to do? Do you want
to have a way, for example, to say just run this test if another test
passes? Or do you want, perhaps, to be able to say don't run this
entire suite unless all of another suite passes? What's the use case?
Thanks.
Bill
OK. One way this could be done is by passing status around in the
configMap. A particular failed test, for example, could cause some
flag to be set in the configMap, and passed down to nested suites.
Those suites could decide to not execute dependent tests. This could
be implemented via traits that get mixed in, and maybe some abstract
member that gets filled in declaring dependencies, or something like
that. Could be done other ways too. But as I said, I'd love to hear
about real use cases from users before setting out to design
something.
Bill