|
|
Re: a bit of feedback
|
Posted: Jan 15, 2008 8:11 PM
|
|
> I haven't tried it out yet, but from looking at the
> documentation:
>
> - The expected and actual values are reversed
> compared to JUnit. In JUnit, the expected value comes
> first. I think this is reasonable, but it's important to
> emphasize the change because it's easy to get wrong.
> (Similarly, the location of the message is reversed.)
>
I didn't realize they were reverse from assertEquals. I'll point that out in the documentation. One of the things I thought was dumb about JUnit originally was that the optional message to assertEquals comes first. Something optional usually comes second. The reason I put actual first is that's the thing we're curious about. It just seemed the natural way to say it.
> - expectNPE and expectIAE are very opaque; a good function
> name should be understandable without looking it up. How
> about naming them throwsNull and throwsIllegalArg?
>
Yes, they are obscure. Eventually Scala may have a way to express non-nullness in the type system, and if so, an NPE may be a rare thing to check for. I don't like your particular suggestions either, but expectIAE is definitely obscure. It could be dropped entirely and added or something else added later based on actual demand. The things I check for most are NPE and IAE though.
> - Iit would be nice if support for test names beginning
> with "should" as well as "test" were the default.
>
Can you explain why you think this? Perhaps give an example?
> - What's the argument for omitting setUp() and
> tearDown()?
>
Basically setUp and tearDown encourage mutable state, and so it kind of goes against the grain of the more functional style encouraged by Scala. Normally you'd reassign mutable instance variables in setUp, clean them up in tearDown, do it again for the next test, etc. What I wanted to encourage instead is that if you really need to share something between test methods, try and make it a val instance variable, not a var. If you can't do that, then you can override any of several methods to do something before and after.
The real difference between ScalaTest and JUnit3/4/TestNG is that in ScalaTest you ask a suite of tests to execute itself by calling its execute method. In JUnit3/4/TestNG the framework executes suites of tests from the outside. This enables people to override execute in ScalaTest for all different kinds of situations to execute tests in custom ways, something that you can't do easily in JUnit3/4/TestNG. One thing you could do, for example, is make a Suite subtrait that calls setUp and tearDown before each test method. When I make the Suite subtraits that support JUnit3/4/TestNG, that's exactly what they'll do. So not having setUp and tearDown is just the default Suite approach. Subtraits and Subclasses of Suite can override that behavior if they want.
> - Any test should easily be run by itself, interactively,
> and it's unclear how to do this if it requires a certain
> test suite.
>
There's an execute method that takes one String, which is the name of a test inside that Suite to execute. You just say something like:
(new MySuite).execute("testAddition")
It will go through all the before and after code you may have added in overridden methods, and then just invoke that one test.
|
|
Previous Topic
