questions about sunit being deprecated, but used in scala testing

On Fri, Dec 11, 2009 at 9:35 PM, Josh Cough wrote:
> All,
>
> SUnit is deprecated:
>
> @deprecated("SUnit will be removed in 2.8.0. There are several free and
> sophisticated testing\n"+
>             "frameworks for Scala available, examples are \"ScalaTest\",
> \"ScalaCheck\" or \"Specs\".")
>
> However, SUnit is still used in several classes in Scala's own test suite.
>
> Does anyone have an idea how this should play out?
>
> Will SUnit just be moved out of the main library to somewhere else, where
> its still available on the test classpath?
> Should Scala's tests be converted to one of the frameworks above?
> If I want to write tests for Scala, should I continue to use SUnit?
>
Certainly not. I think we should try to move these tests over to some
more modern testing framework. Right now, it seems nobidy takes
ownerships of these tests so they are up for grabs.

Cheers

On the other hand I thought that those tests kept using SUnit so they wouldn't be too fragile in front of Scala changes.
Indeed if you introduce a significant change in the language you don't want your tests to break because the test harness breaks. SUnit is simple enough to give you confidence that a failing test is directly related to the change just introduced.
Don't you think so?
 ----------------------------------------------
Eric TORREBORRE
T +61 411 707 402
E etorreborre@yahoo.com
B http://etorreborre.blogspot.com
P http://specs.googlecode.com
----------------------------------------------

De : martin odersky <martin.odersky@epfl.ch>
À : Josh Cough <joshcough@gmail.com>
Cc : scala-internals@listes.epfl.ch
Envoyé le : Sam 12 Décembre 2009, 8 h 06 min 02 s
Objet : Re: [scala-internals] questions about sunit being deprecated, but used in scala testing

On Fri, Dec 11, 2009 at 9:35 PM, Josh Cough <joshcough@gmail.com> wrote:
> All,
>
> SUnit is deprecated:
>
> @deprecated("SUnit will be removed in 2.8.0. There are several free and
> sophisticated testing\n"+
>             "frameworks for Scala available, examples are \"ScalaTest\",
> \"ScalaCheck\" or \"Specs\".")
>
> However, SUnit is still used in several classes in Scala's own test suite.
>
> Does anyone have an idea how this should play out?
>
> Will SUnit just be moved out of the main library to somewhere else, where
> its still available on the test classpath?
> Should Scala's tests be converted to one of the frameworks above?
> If I want to write tests for Scala, should I continue to use SUnit?
>
Certainly not. I think we should try to move these tests over to some
more modern testing framework. Right now, it seems nobidy takes
ownerships of these tests so they are up for grabs.

Cheers

-- Martin

Eric Torreborre schrieb:
> On the other hand I thought that those tests kept using SUnit so they
> wouldn't be too fragile in front of Scala changes.
>
> Indeed if you introduce a significant change in the language you don't
> want your tests to break because the test harness breaks. SUnit is
> simple enough to give you confidence that a failing test is directly
> related to the change just introduced.
>
> Don't you think so?
>
> ----------------------------------------------
> Eric TORREBORRE
> T +61 411 707 402
> E etorreborre@yahoo.com
> B http://etorreborre.blogspot.com
> P http://specs.googlecode.com
> ----------------------------------------------
>
>
> ------------------------------------------------------------------------
> *De :* martin odersky
> *À :* Josh Cough
> *Cc :* scala-internals@listes.epfl.ch
> *Envoyé le :* Sam 12 Décembre 2009, 8 h 06 min 02 s
> *Objet :* Re: [scala-internals] questions about sunit being
> deprecated, but used in scala testing
>
> On Fri, Dec 11, 2009 at 9:35 PM, Josh Cough > wrote:
> > All,
> >
> > SUnit is deprecated:
> >
> > @deprecated("SUnit will be removed in 2.8.0. There are several free and
> > sophisticated testing\n"+
> > "frameworks for Scala available, examples are \"ScalaTest\",
> > \"ScalaCheck\" or \"Specs\".")
> >
> > However, SUnit is still used in several classes in Scala's own test
> suite.
> >
> > Does anyone have an idea how this should play out?
> >
> > Will SUnit just be moved out of the main library to somewhere else,
> where
> > its still available on the test classpath?
> > Should Scala's tests be converted to one of the frameworks above?
> > If I want to write tests for Scala, should I continue to use SUnit?
> >
> Certainly not. I think we should try to move these tests over to some
> more modern testing framework. Right now, it seems nobidy takes
> ownerships of these tests so they are up for grabs.
>
> Cheers
>

On Sat, Dec 12, 2009 at 8:35 AM, Andres Nötzli wrote:
> Eric Torreborre schrieb:
>>
>> On the other hand I thought that those tests kept using SUnit so they
>> wouldn't be too fragile in front of Scala changes.
>>
>> Indeed if you introduce a significant change in the language you don't
>> want your tests to break because the test harness breaks. SUnit is simple
>> enough to give you confidence that a failing test is directly related to the
>> change just introduced.
>>
>> Don't you think so?

Yes, maybe. I agree we want to keep the testing framework simple.

But I believe all these things are really more by accident than
anything else. Nobody has yet taken ownership of the testing procedure
as a whole. So things tend to stay as they are (which is by itself not
a bad thing, unless we want to pour much more resources into this.

Cheers

On Fri, Dec 11, 2009 at 07:52:12PM -0800, Eric Torreborre wrote:
> On the other hand I thought that those tests kept using SUnit so they
> wouldn't be too fragile in front of Scala changes.
>
> Indeed if you introduce a significant change in the language you don't
> want your tests to break because the test harness breaks. SUnit is
> simple enough to give you confidence that a failing test is directly
> related to the change just introduced.

This point is not without merit. On the other hand, in my opinion this
development cycle was the last time scala can be allowed to fly with so
little anchoring it. Using an outside testing framework in trunk would
give us immediate consquence feedback from another source base. This
could be accomplished by other means, but it's harder to tune something
out when it's your primary testing rig failing.