You can do what we did in my team: decide on a style of testing and stick to it (in our case, I liked WordSpec). With JUnit you can't do this, because there is only one style.
I particularly liked the "should", "must", "where", etc. DSL. If I remember correctly, this style of testing comes from the Rails community. I guess it's a matter of taste, but I would definitely recommend it to newbies.
I wouldn't recommend it to newbies at all, because it's using relatively advanced Scala features - implicit conversions to make the operators available, "word word word" style desugaring into method calls. Of course these are things that you have to learn eventually and that have value, but making a newbie learn how they work before they can test anything is throwing them in at the deep end, and having to use a test framework that you can't understand isn't good.
A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument.
The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes". To me, ScalaTest with WordSpec seems more natural than JUnit, and at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
> A lot of Java programmers don't understand how JUnit works, nor need to, and they still manage to use it, so I don't think this is a strong argument.
What's to understand? You write a method in plain old java, and the framework runs it.
> The point of DSLs is that they feel natural for their job, regardless of how they are implemented. You can use a DSL without understanding how it works "behind the scenes".
The point of "embedded DSLs" is that they follow the ordinary rules of the host language. Otherwise they're no better than an external config file, Cucumber-style (which some people apparently like, but I find utterly unusable).
> at least my own experience shows I'm right: I've successfully introduced it in a team of newbies.
When they make a change to code that breaks a test, and you're not there, how long does it take them to understand what's gone wrong? That's the real test of a test framework, and IME ScalaTest does very badly on it.
Let me ask your own question back at you: what's there to understand with WordSpec or Cucumber-style tests? It's just a tool, you just use it as documented... just like you don't need to even look at JUnit's implementation in order to use it.
Yes, when a WordSpec test starts failing, junior devs know how to fix it without my assistance. I haven't noticed any difference in dev effectiveness between ScalaTest and JUnit.
> Let me ask your own question back at you: what's there to understand with WordSpec or Cucumber-style tests?
To use Cucumber you have to understand a whole new grammar. To use ScalaTest you have to understand relatively obscure parts of Scala (implicit conversions, "word word word" style method calls, by-name parameters, ...) - or else treat it like a config file and learn a whole new grammar. To use JUnit you just write plain old Java/Scala.
I particularly liked the "should", "must", "where", etc. DSL. If I remember correctly, this style of testing comes from the Rails community. I guess it's a matter of taste, but I would definitely recommend it to newbies.