ScalaTest test cases with Scalatra, mixing in WordSpec, FlatSpec, etc...
saem
I tried mixing in the WordSpec xor FlatSpec into test cases I wanted
to write, and it barfed on me with some errors, about how run was
defined in both traits (whichever one I mixed in and
BeforeAndAfterAll). Some googling turned up that BeforeAndAfterAll or
BeforeAndAfterEach needs to be mixed in LAST.
With the current implementation of ScalatraSuite this isn't workable.
The obvious and kinda sucky work around is to create ScalatraSuite
traits which inherit from each of the appropriate trait such that
there is appropriate functionality as desired.
Ross A. Baker
Hmm, that is sucky. I hadn't noticed because I tend to use
ScalatraFunSuite, which is an example of the sucky workaround.
BeforeAndAfterAll could be made part of the self type, but then
everyone would have to mix it in themselves, which is even suckier.
The best solution I can think of is to bundle more of your proposed
sucky traits, and make BeforeAndAfterAll part of ScalatraSuite's self
type in case the bundled sucky traits are insufficient. Any better
ideas?
Logged as http://github.com/scalatra/scalatra/issues/issue/21
--
Ross A. Baker
ba...@alumni.indiana.edu
Indianapolis, IN, USA
Ross A. Baker
Now that I've looked at this a little more closely, you just need to
be sure that ScalatraSuite is mixed in after your Suite implementation
(e.g., WordSpec, FunSuite). That satisfies the ScalaTest constraint
that BeforeAndAfterAll comes last:
class MyTest extends WordSpec with ScalatraSuite // compiles
class MyTest extends ScalatraSuite with WordSpec // doesn't compile
To DRY things up for common combinations, we could of course create
traits like ScalatraWordSpec similar to the existing ScalatraFunSuite
(patches welcome). It's just not mandatory, as long as the traits are
mixed in the proper order.
I will leave the issue open so this gotcha is documented in the
Scaladoc and the README.
saem
On Nov 29, 10:14 pm, "Ross A. Baker" <ba...@alumni.indiana.edu> wrote:
> > Hi,
>
> > I tried mixing in the WordSpec xor FlatSpec into test cases I wanted
> > to write, and it barfed on me with some errors, about how run was
> > defined in both traits (whichever one I mixed in and
> > BeforeAndAfterAll). Some googling turned up that BeforeAndAfterAll or
> > BeforeAndAfterEach needs to be mixed in LAST.
>
> > With the current implementation of ScalatraSuite this isn't workable.
>
> be sure that ScalatraSuite is mixed in after your Suite implementation
> (e.g., WordSpec, FunSuite). That satisfies the ScalaTest constraint
> that BeforeAndAfterAll comes last:
>
> class MyTest extends WordSpec with ScalatraSuite // compiles
>
> class MyTest extends ScalatraSuite with WordSpec // doesn't compile
>
those before and after methods were doing.
> To DRY things up for common combinations, we could of course create
> traits like ScalatraWordSpec similar to the existing ScalatraFunSuite
> (patches welcome). It's just not mandatory, as long as the traits are
> mixed in the proper order.
time and whip up those files -- have to say on class per file is kinda
gross for this kinda stuff, which seems to be the general trend for
Scalatra.
> I will leave the issue open so this gotcha is documented in the
> Scaladoc and the README.
Ross A. Baker
> That sounds pretty straight forward, I'll see if I can get some free
> time and whip up those files -- have to say on class per file is kinda
> gross for this kinda stuff, which seems to be the general trend for
> Scalatra.
Well, 13 years of Java habits die hard. :-) Quoting from the Scala
Style Guide[1]: "Another case is when multiple classes logically form
a single, cohesive group, sharing concepts to the point where
maintenance is greatly served by containing them within a single
file... Generally speaking, if it is easier to perform long-term
maintenance and development on several units in a single file rather
than spread across multiple, then such an organizational strategy
should be preferred for these classes." I think that could certainly
apply to these test traits.
On the subject of the style guide, I highly recommend that everyone
familiarize themselves with it. Scala developers come from diverse
backgrounds -- Java, Ruby, Haskell, etc. -- all of which bring useful
insights. But we still need to navigate, understand, and patch each
other's code. The SSG is a good step toward making us play nicely
together.
[1] - http://davetron5000.github.com/scala-style/files/multi_unit_files.html