ScalaTest 0.9.5 released!

Congratulations!

On Tue, Mar 3, 2009 at 4:56 PM, Bill Venners <bill@artima.com> wrote:

Hi All,

I'd to announce that ScalaTest 0.9.5 is out the door and ready for
download. This a rather major release that includes a matchers DSL and
enhancements to the GUI designed to improve your productivity. You can
get ScalaTest from here:

http://www.artima.com/scalatest

Here's an overview of what ScalaTest is all about, taken from its home page:

ScalaTest is a free, open-source testing tool for Scala and Java
programmers. It is written in Scala, and enables you to write tests in
Scala to test either Scala or Java code. It is released under the
Apache 2.0 open source license.

Because different developers take different approaches to creating
software, no single approach to testing is a good fit for everyone. In
light of this reality, ScalaTest is designed to facilitate different
styles of testing. ScalaTest provides several traits that you can mix
together into whatever combination makes you feel the most productive.

For behavior-driven developers

For example, if you like the behavior-driven development style of
testing, in which tests are viewed as informal specifications of the
code under test, you might mix trait Spec with trait ShouldMatchers.
Your tests would look something like:

class StackSpec extends Spec with ShouldMatchers {

 describe("A Stack") {

   it("should pop values in last-in-first-out order") {
     val stack = new Stack[Int]
     stack.push(1)
     stack.push(2)
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }

   it("should be empty when created") {
     val stack = new Stack[Int]
     stack should be ('empty)
   }
 }
}

When you run this Spec its output will be structured as an
easy-to-read informal specification of the Stack it tests. ScalaTest
can format the specification output in its GUI or in text. In text, it
would look like:

A Stack
- should pop values in last-in-first-out order
- should be empty when created

ScalaTest's ShouldMatchers provide an elegant DSL for expressing
assertions, which can make the code more readable and failure messages
easier to understand. Some other examples are:

map should (contain key ("one") and not contain value (10))
result should be >= (0)
book should have (title ("Programming in Scala"))
tempFile should not be a ('directory)
quotient should be (1.0 plusOrMinus 0.2)

For more traditional testers

As elegant and readable as the matcher expressions may seem to some,
you may find them too verbose for your taste. You may also prefer to
think of tests as, well, tests rather than as specifications, and you
also may find you often need to test private methods. If this
describes you, you might mix trait FunSuite with trait
PrivateMethodTester, yielding tests that look like:

class StackSuite extends FunSuite with PrivateMethodTester {

 test("Stack should pop values in last-in-first-out order") {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 test("Stack should throw NoSuchElementException if an empty stack is
popped") {
   val emptyStack = new Stack[String]
   intercept[NoSuchElementException] {
     emptyStack.pop()
   }
 }

 test("Stack's private decorate method should place quotes around strings") {
   val stack = new Stack[String]
   val decorate = PrivateMethod[String]('decorate)
   val result = stack invokePrivate decorate("hello")
   assert(result === "\"hello\"")
 }
}

For TestNG enthusiasts

Or perhaps you've been using TestNG in Java, and you want to continue
using it in Scala. You like the matchers DSL, but prefer the word
"must" to "should". If this sounds like you, you can mix trait
TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
TestNG will be happy to run them, as will ScalaTest) that look like
this:

class StackSuite extends TestNGSuite with MustMatchers {

 @Test def mustPopInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   stack.pop() must equal (2)
   stack.pop() must equal (1)
 }

 @Test def mustBeEmptyWhenCreated() {
   val stack = new Stack[Int]
   stack must be ('empty)
 }
}

For JUnit and ScalaCheck users

ScalaTest also provides traits that support writing JUnit tests in
Java, combining the benefits of using the established defacto standard
testing tool for the Java community with the more concise, readable
syntax of ScalaTest assertions and matchers. If you want to write
JUnit tests in Scala, but also really like the bang for the buck you
get by writing ScalaCheck property checks, you might mix trait
JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
testing trait, including the Spec, FunSuite, and TestNGSuite traits
shown previously, to include ScalaCheck property checks among
traditional assertions.) This would give you tests that look like:

class StackSuite extends JUnit3Suite with Checkers {

 def testPopsInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 def testIsEmptyWhenCreated() {
   val stack = new Stack[Int]
   assert(stack.isEmpty)
 }

 def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
property check
   check(
     (list: List[Int]) => {
       val stack = new Stack[Int]
       for (element <- list) stack.push(element)
       stack.elements.toList == list
     }
   )
 }
}

And more...

If you have some other preference, ScalaTest is designed to be
extended, so you can create your own testing traits that look and act
exactly as you want. In short, ScalaTest is about productivity, your
productivity. You can mix ScalaTest traits together into whatever
combination creates the testing tool you find the most fun and
productive to use.

Enjoy.

Bill
---
Bill Venners
Artima, Inc.
http://www.artima.com

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Bill, did you announce the new scalatest-users Google group?

http://groups.google.com/group/scalatest-users

I just did it for you, if not ;)

dean

On Tue, Mar 3, 2009 at 6:56 PM, Bill Venners <bill@artima.com> wrote:

Hi All,

I'd to announce that ScalaTest 0.9.5 is out the door and ready for
download. This a rather major release that includes a matchers DSL and
enhancements to the GUI designed to improve your productivity. You can
get ScalaTest from here:

http://www.artima.com/scalatest

Here's an overview of what ScalaTest is all about, taken from its home page:

ScalaTest is a free, open-source testing tool for Scala and Java
programmers. It is written in Scala, and enables you to write tests in
Scala to test either Scala or Java code. It is released under the
Apache 2.0 open source license.

Because different developers take different approaches to creating
software, no single approach to testing is a good fit for everyone. In
light of this reality, ScalaTest is designed to facilitate different
styles of testing. ScalaTest provides several traits that you can mix
together into whatever combination makes you feel the most productive.

For behavior-driven developers

For example, if you like the behavior-driven development style of
testing, in which tests are viewed as informal specifications of the
code under test, you might mix trait Spec with trait ShouldMatchers.
Your tests would look something like:

class StackSpec extends Spec with ShouldMatchers {

 describe("A Stack") {

   it("should pop values in last-in-first-out order") {
     val stack = new Stack[Int]
     stack.push(1)
     stack.push(2)
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }

   it("should be empty when created") {
     val stack = new Stack[Int]
     stack should be ('empty)
   }
 }
}

When you run this Spec its output will be structured as an
easy-to-read informal specification of the Stack it tests. ScalaTest
can format the specification output in its GUI or in text. In text, it
would look like:

A Stack
- should pop values in last-in-first-out order
- should be empty when created

ScalaTest's ShouldMatchers provide an elegant DSL for expressing
assertions, which can make the code more readable and failure messages
easier to understand. Some other examples are:

map should (contain key ("one") and not contain value (10))
result should be >= (0)
book should have (title ("Programming in Scala"))
tempFile should not be a ('directory)
quotient should be (1.0 plusOrMinus 0.2)

For more traditional testers

As elegant and readable as the matcher expressions may seem to some,
you may find them too verbose for your taste. You may also prefer to
think of tests as, well, tests rather than as specifications, and you
also may find you often need to test private methods. If this
describes you, you might mix trait FunSuite with trait
PrivateMethodTester, yielding tests that look like:

class StackSuite extends FunSuite with PrivateMethodTester {

 test("Stack should pop values in last-in-first-out order") {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 test("Stack should throw NoSuchElementException if an empty stack is
popped") {
   val emptyStack = new Stack[String]
   intercept[NoSuchElementException] {
     emptyStack.pop()
   }
 }

 test("Stack's private decorate method should place quotes around strings") {
   val stack = new Stack[String]
   val decorate = PrivateMethod[String]('decorate)
   val result = stack invokePrivate decorate("hello")
   assert(result === "\"hello\"")
 }
}

For TestNG enthusiasts

Or perhaps you've been using TestNG in Java, and you want to continue
using it in Scala. You like the matchers DSL, but prefer the word
"must" to "should". If this sounds like you, you can mix trait
TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
TestNG will be happy to run them, as will ScalaTest) that look like
this:

class StackSuite extends TestNGSuite with MustMatchers {

 @Test def mustPopInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   stack.pop() must equal (2)
   stack.pop() must equal (1)
 }

 @Test def mustBeEmptyWhenCreated() {
   val stack = new Stack[Int]
   stack must be ('empty)
 }
}

For JUnit and ScalaCheck users

ScalaTest also provides traits that support writing JUnit tests in
Java, combining the benefits of using the established defacto standard
testing tool for the Java community with the more concise, readable
syntax of ScalaTest assertions and matchers. If you want to write
JUnit tests in Scala, but also really like the bang for the buck you
get by writing ScalaCheck property checks, you might mix trait
JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
testing trait, including the Spec, FunSuite, and TestNGSuite traits
shown previously, to include ScalaCheck property checks among
traditional assertions.) This would give you tests that look like:

class StackSuite extends JUnit3Suite with Checkers {

 def testPopsInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 def testIsEmptyWhenCreated() {
   val stack = new Stack[Int]
   assert(stack.isEmpty)
 }

 def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
property check
   check(
     (list: List[Int]) => {
       val stack = new Stack[Int]
       for (element <- list) stack.push(element)
       stack.elements.toList == list
     }
   )
 }
}

And more...

If you have some other preference, ScalaTest is designed to be
extended, so you can create your own testing traits that look and act
exactly as you want. In short, ScalaTest is about productivity, your
productivity. You can mix ScalaTest traits together into whatever
combination creates the testing tool you find the most fun and
productive to use.

Enjoy.

Bill
---
Bill Venners
Artima, Inc.
http://www.artima.com

--
Dean Wampler
twitter: @deanwampler, @chicagoscala
Chicago-Area Scala Enthusiasts (CASE):
-  http://groups.google.com/group/chicagoscala
-  http://www.meetup.com/chicagoscala/ (Meetings)
http://www.objectmentor.com
http://www.polyglotprogramming.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

Isn't it possible to merge specs and ScalaTest somehow?

S.

On Wed, Mar 4, 2009 at 03:56, Bill Venners wrote:
> Hi All,
>
> I'd to announce that ScalaTest 0.9.5 is out the door and ready for
> download. This a rather major release that includes a matchers DSL and
> enhancements to the GUI designed to improve your productivity. You can
> get ScalaTest from here:
>
> http://www.artima.com/scalatest
>
> Here's an overview of what ScalaTest is all about, taken from its home page:
>
> ScalaTest is a free, open-source testing tool for Scala and Java
> programmers. It is written in Scala, and enables you to write tests in
> Scala to test either Scala or Java code. It is released under the
> Apache 2.0 open source license.
>
> Because different developers take different approaches to creating
> software, no single approach to testing is a good fit for everyone. In
> light of this reality, ScalaTest is designed to facilitate different
> styles of testing. ScalaTest provides several traits that you can mix
> together into whatever combination makes you feel the most productive.
>
> For behavior-driven developers
>
> For example, if you like the behavior-driven development style of
> testing, in which tests are viewed as informal specifications of the
> code under test, you might mix trait Spec with trait ShouldMatchers.
> Your tests would look something like:
>
> class StackSpec extends Spec with ShouldMatchers {
>
>  describe("A Stack") {
>
>    it("should pop values in last-in-first-out order") {
>      val stack = new Stack[Int]
>      stack.push(1)
>      stack.push(2)
>      stack.pop() should equal (2)
>      stack.pop() should equal (1)
>    }
>
>    it("should be empty when created") {
>      val stack = new Stack[Int]
>      stack should be ('empty)
>    }
>  }
> }
>
> When you run this Spec its output will be structured as an
> easy-to-read informal specification of the Stack it tests. ScalaTest
> can format the specification output in its GUI or in text. In text, it
> would look like:
>
> A Stack
> - should pop values in last-in-first-out order
> - should be empty when created
>
> ScalaTest's ShouldMatchers provide an elegant DSL for expressing
> assertions, which can make the code more readable and failure messages
> easier to understand. Some other examples are:
>
> map should (contain key ("one") and not contain value (10))
> result should be >= (0)
> book should have (title ("Programming in Scala"))
> tempFile should not be a ('directory)
> quotient should be (1.0 plusOrMinus 0.2)
>
> For more traditional testers
>
> As elegant and readable as the matcher expressions may seem to some,
> you may find them too verbose for your taste. You may also prefer to
> think of tests as, well, tests rather than as specifications, and you
> also may find you often need to test private methods. If this
> describes you, you might mix trait FunSuite with trait
> PrivateMethodTester, yielding tests that look like:
>
> class StackSuite extends FunSuite with PrivateMethodTester {
>
>  test("Stack should pop values in last-in-first-out order") {
>    val stack = new Stack[Int]
>    stack.push(1)
>    stack.push(2)
>    assert(stack.pop() === (2))
>    assert(stack.pop() === (1))
>  }
>
>  test("Stack should throw NoSuchElementException if an empty stack is
> popped") {
>    val emptyStack = new Stack[String]
>    intercept[NoSuchElementException] {
>      emptyStack.pop()
>    }
>  }
>
>  test("Stack's private decorate method should place quotes around strings") {
>    val stack = new Stack[String]
>    val decorate = PrivateMethod[String]('decorate)
>    val result = stack invokePrivate decorate("hello")
>    assert(result === "\"hello\"")
>  }
> }
>
> For TestNG enthusiasts
>
> Or perhaps you've been using TestNG in Java, and you want to continue
> using it in Scala. You like the matchers DSL, but prefer the word
> "must" to "should". If this sounds like you, you can mix trait
> TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
> TestNG will be happy to run them, as will ScalaTest) that look like
> this:
>
> class StackSuite extends TestNGSuite with MustMatchers {
>
>  @Test def mustPopInLifoOrder() {
>    val stack = new Stack[Int]
>    stack.push(1)
>    stack.push(2)
>    stack.pop() must equal (2)
>    stack.pop() must equal (1)
>  }
>
>  @Test def mustBeEmptyWhenCreated() {
>    val stack = new Stack[Int]
>    stack must be ('empty)
>  }
> }
>
> For JUnit and ScalaCheck users
>
> ScalaTest also provides traits that support writing JUnit tests in
> Java, combining the benefits of using the established defacto standard
> testing tool for the Java community with the more concise, readable
> syntax of ScalaTest assertions and matchers. If you want to write
> JUnit tests in Scala, but also really like the bang for the buck you
> get by writing ScalaCheck property checks, you might mix trait
> JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
> testing trait, including the Spec, FunSuite, and TestNGSuite traits
> shown previously, to include ScalaCheck property checks among
> traditional assertions.) This would give you tests that look like:
>
> class StackSuite extends JUnit3Suite with Checkers {
>
>  def testPopsInLifoOrder() {
>    val stack = new Stack[Int]
>    stack.push(1)
>    stack.push(2)
>    assert(stack.pop() === (2))
>    assert(stack.pop() === (1))
>  }
>
>  def testIsEmptyWhenCreated() {
>    val stack = new Stack[Int]
>    assert(stack.isEmpty)
>  }
>
>  def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
> property check
>    check(
>      (list: List[Int]) => {
>        val stack = new Stack[Int]
>        for (element <- list) stack.push(element)
>        stack.elements.toList == list
>      }
>    )
>  }
> }
>
> And more...
>
> If you have some other preference, ScalaTest is designed to be
> extended, so you can create your own testing traits that look and act
> exactly as you want. In short, ScalaTest is about productivity, your
> productivity. You can mix ScalaTest traits together into whatever
> combination creates the testing tool you find the most fun and
> productive to use.
>
> Enjoy.
>
> Bill
> ---
> Bill Venners
> Artima, Inc.
> http://www.artima.com
>

Hi Stepan,

Well, Eric and I have been working on improving the integration bit by
bit. We still have more to do.

Basically a driving philosophy of ScalaTest's design is that different
people like to do things in different ways, and one of the ways I'd
like ScalaTest to support is the Specs way. The first thing I did is
ask Eric if he would create a matchers trait you can mix into test
classes other than Specs' Specifications. He created the
org.specs.SpecsMatchers trait. So if you like ScalaTest's Spec (the
describe and it syntax, like RSpec) better than Specs's Specification
syntax that uses implicit conversions on strings, but you like Specs'
matchers, you could do this:

import org.scalatest.Spec
import org.specs.SpecsMatchers

class MySpec extends Spec with SpecsMatchers { ... }

So that was one point of integration. Eric had already provided a way
to run Specs tests through ScalaTest, but I then wanted to create a
way for those runs to look like a specification output. So I created
this class called SpecReport, which Eric is now working to start
sending instead of plain old Reports. The latest release of ScalaTest
will show SpecReports in the GUI in a specification-style, so once
Eric gets those SpecReports going you'll be able to run Specs tests
through ScalaTest and get a nice specification-style feedback in
ScalaTest's GUI.

Two other things I want to add in the next ScalaTest release, though,
is the ability for a SpecReport to specify an indentation level,
because Specs output is hierarchical (as is JUnit's by the way).
ScalaTest's output is flat. So that's one enhancement that will
improve Specs support in ScalaTest. I also want to add an elapsed time
field to the runCompleted reports, both because people like that in
general but also because Specs already tracks that and I'd like it to
show up when Specs reports get run through ScalaTest.

As far as merging the projects, I don't think that's really needed.
The different projects take different approaches to solving problems,
and I think it's good for users to have choices and for Eric and I to
push each other a bit. The reason I created a native BDD option in
ScalaTest instead of just integrating Specs like I did with ScalaCheck
was precisely because I myself wasn't quite comfortable with the
Specs' syntax for matchers or Specification. So differences in style
like:

a must be_==(b) // Specs
a must equal (b) // ScalaTest

or

a must beGreaterThanOrEqualTo(b) // Specs
a must be >= (b) // ScalaTest

Etc. I also wasn't quite comfortable with the use of should when
specifying the context, which burns should, and then being forced to
use must for the assertions. I kind of prefer should for assertions,
though I've met a lot of people who prefer must. But to use one to
mean one thing and the other something else was a bit of a dissonance
to me, and I wanted to give people a choice between must and should.

So there's some overlap here, but I think it is good that people have
choices. ScalaTest matchers does more with Scala's operator notation,
which I think makes the syntax more elegant in general, but there are
tradeoffs. For example when you and or or matchers together in Specs,
they short circuit (I think), but in ScalaTest, they don't. The reason
is that short circuiting is in some cases not possible to do when
separating the words out in operator notation like ScalaTest does, so
I just don't do it everywhere to be consistent:

map must (notHaveKey(7) and notHaveSize(8)) // Specs, will
short circuit if map has key 7
map must (not contain key (7) and not have size (8)) // ScalaTest,
won't short circuit, even if map has key 7

It's usually not going to matter, but it is a difference.

Bill

On Wed, Mar 4, 2009 at 8:57 AM, Stepan Koltsov wrote:
> Isn't it possible to merge specs and ScalaTest somehow?
>
> S.
>
> On Wed, Mar 4, 2009 at 03:56, Bill Venners wrote:
>> Hi All,
>>
>> I'd to announce that ScalaTest 0.9.5 is out the door and ready for
>> download. This a rather major release that includes a matchers DSL and
>> enhancements to the GUI designed to improve your productivity. You can
>> get ScalaTest from here:
>>
>> http://www.artima.com/scalatest
>>
>> Here's an overview of what ScalaTest is all about, taken from its home page:
>>
>> ScalaTest is a free, open-source testing tool for Scala and Java
>> programmers. It is written in Scala, and enables you to write tests in
>> Scala to test either Scala or Java code. It is released under the
>> Apache 2.0 open source license.
>>
>> Because different developers take different approaches to creating
>> software, no single approach to testing is a good fit for everyone. In
>> light of this reality, ScalaTest is designed to facilitate different
>> styles of testing. ScalaTest provides several traits that you can mix
>> together into whatever combination makes you feel the most productive.
>>
>> For behavior-driven developers
>>
>> For example, if you like the behavior-driven development style of
>> testing, in which tests are viewed as informal specifications of the
>> code under test, you might mix trait Spec with trait ShouldMatchers.
>> Your tests would look something like:
>>
>> class StackSpec extends Spec with ShouldMatchers {
>>
>>  describe("A Stack") {
>>
>>    it("should pop values in last-in-first-out order") {
>>      val stack = new Stack[Int]
>>      stack.push(1)
>>      stack.push(2)
>>      stack.pop() should equal (2)
>>      stack.pop() should equal (1)
>>    }
>>
>>    it("should be empty when created") {
>>      val stack = new Stack[Int]
>>      stack should be ('empty)
>>    }
>>  }
>> }
>>
>> When you run this Spec its output will be structured as an
>> easy-to-read informal specification of the Stack it tests. ScalaTest
>> can format the specification output in its GUI or in text. In text, it
>> would look like:
>>
>> A Stack
>> - should pop values in last-in-first-out order
>> - should be empty when created
>>
>> ScalaTest's ShouldMatchers provide an elegant DSL for expressing
>> assertions, which can make the code more readable and failure messages
>> easier to understand. Some other examples are:
>>
>> map should (contain key ("one") and not contain value (10))
>> result should be >= (0)
>> book should have (title ("Programming in Scala"))
>> tempFile should not be a ('directory)
>> quotient should be (1.0 plusOrMinus 0.2)
>>
>> For more traditional testers
>>
>> As elegant and readable as the matcher expressions may seem to some,
>> you may find them too verbose for your taste. You may also prefer to
>> think of tests as, well, tests rather than as specifications, and you
>> also may find you often need to test private methods. If this
>> describes you, you might mix trait FunSuite with trait
>> PrivateMethodTester, yielding tests that look like:
>>
>> class StackSuite extends FunSuite with PrivateMethodTester {
>>
>>  test("Stack should pop values in last-in-first-out order") {
>>    val stack = new Stack[Int]
>>    stack.push(1)
>>    stack.push(2)
>>    assert(stack.pop() === (2))
>>    assert(stack.pop() === (1))
>>  }
>>
>>  test("Stack should throw NoSuchElementException if an empty stack is
>> popped") {
>>    val emptyStack = new Stack[String]
>>    intercept[NoSuchElementException] {
>>      emptyStack.pop()
>>    }
>>  }
>>
>>  test("Stack's private decorate method should place quotes around strings") {
>>    val stack = new Stack[String]
>>    val decorate = PrivateMethod[String]('decorate)
>>    val result = stack invokePrivate decorate("hello")
>>    assert(result === "\"hello\"")
>>  }
>> }
>>
>> For TestNG enthusiasts
>>
>> Or perhaps you've been using TestNG in Java, and you want to continue
>> using it in Scala. You like the matchers DSL, but prefer the word
>> "must" to "should". If this sounds like you, you can mix trait
>> TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
>> TestNG will be happy to run them, as will ScalaTest) that look like
>> this:
>>
>> class StackSuite extends TestNGSuite with MustMatchers {
>>
>>  @Test def mustPopInLifoOrder() {
>>    val stack = new Stack[Int]
>>    stack.push(1)
>>    stack.push(2)
>>    stack.pop() must equal (2)
>>    stack.pop() must equal (1)
>>  }
>>
>>  @Test def mustBeEmptyWhenCreated() {
>>    val stack = new Stack[Int]
>>    stack must be ('empty)
>>  }
>> }
>>
>> For JUnit and ScalaCheck users
>>
>> ScalaTest also provides traits that support writing JUnit tests in
>> Java, combining the benefits of using the established defacto standard
>> testing tool for the Java community with the more concise, readable
>> syntax of ScalaTest assertions and matchers. If you want to write
>> JUnit tests in Scala, but also really like the bang for the buck you
>> get by writing ScalaCheck property checks, you might mix trait
>> JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
>> testing trait, including the Spec, FunSuite, and TestNGSuite traits
>> shown previously, to include ScalaCheck property checks among
>> traditional assertions.) This would give you tests that look like:
>>
>> class StackSuite extends JUnit3Suite with Checkers {
>>
>>  def testPopsInLifoOrder() {
>>    val stack = new Stack[Int]
>>    stack.push(1)
>>    stack.push(2)
>>    assert(stack.pop() === (2))
>>    assert(stack.pop() === (1))
>>  }
>>
>>  def testIsEmptyWhenCreated() {
>>    val stack = new Stack[Int]
>>    assert(stack.isEmpty)
>>  }
>>
>>  def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
>> property check
>>    check(
>>      (list: List[Int]) => {
>>        val stack = new Stack[Int]
>>        for (element <- list) stack.push(element)
>>        stack.elements.toList == list
>>      }
>>    )
>>  }
>> }
>>
>> And more...
>>
>> If you have some other preference, ScalaTest is designed to be
>> extended, so you can create your own testing traits that look and act
>> exactly as you want. In short, ScalaTest is about productivity, your
>> productivity. You can mix ScalaTest traits together into whatever
>> combination creates the testing tool you find the most fun and
>> productive to use.
>>
>> Enjoy.
>>
>> Bill
>> ---
>> Bill Venners
>> Artima, Inc.
>> http://www.artima.com
>>
>

Awesome. Good work.

2009/3/4 Bill Venners :
> Hi All,
>
> I'd to announce that ScalaTest 0.9.5 is out the door and ready for
> download. This a rather major release that includes a matchers DSL and
> enhancements to the GUI designed to improve your productivity. You can
> get ScalaTest from here:
>
> http://www.artima.com/scalatest
>
> Here's an overview of what ScalaTest is all about, taken from its home page:
>
> ScalaTest is a free, open-source testing tool for Scala and Java
> programmers. It is written in Scala, and enables you to write tests in
> Scala to test either Scala or Java code. It is released under the
> Apache 2.0 open source license.
>
> Because different developers take different approaches to creating
> software, no single approach to testing is a good fit for everyone. In
> light of this reality, ScalaTest is designed to facilitate different
> styles of testing. ScalaTest provides several traits that you can mix
> together into whatever combination makes you feel the most productive.
>
> For behavior-driven developers
>
> For example, if you like the behavior-driven development style of
> testing, in which tests are viewed as informal specifications of the
> code under test, you might mix trait Spec with trait ShouldMatchers.
> Your tests would look something like:
>
> class StackSpec extends Spec with ShouldMatchers {
>
>  describe("A Stack") {
>
>    it("should pop values in last-in-first-out order") {
>      val stack = new Stack[Int]
>      stack.push(1)
>      stack.push(2)
>      stack.pop() should equal (2)
>      stack.pop() should equal (1)
>    }
>
>    it("should be empty when created") {
>      val stack = new Stack[Int]
>      stack should be ('empty)
>    }
>  }
> }
>
> When you run this Spec its output will be structured as an
> easy-to-read informal specification of the Stack it tests. ScalaTest
> can format the specification output in its GUI or in text. In text, it
> would look like:
>
> A Stack
> - should pop values in last-in-first-out order
> - should be empty when created
>
> ScalaTest's ShouldMatchers provide an elegant DSL for expressing
> assertions, which can make the code more readable and failure messages
> easier to understand. Some other examples are:
>
> map should (contain key ("one") and not contain value (10))
> result should be >= (0)
> book should have (title ("Programming in Scala"))
> tempFile should not be a ('directory)
> quotient should be (1.0 plusOrMinus 0.2)
>
> For more traditional testers
>
> As elegant and readable as the matcher expressions may seem to some,
> you may find them too verbose for your taste. You may also prefer to
> think of tests as, well, tests rather than as specifications, and you
> also may find you often need to test private methods. If this
> describes you, you might mix trait FunSuite with trait
> PrivateMethodTester, yielding tests that look like:
>
> class StackSuite extends FunSuite with PrivateMethodTester {
>
>  test("Stack should pop values in last-in-first-out order") {
>    val stack = new Stack[Int]
>    stack.push(1)
>    stack.push(2)
>    assert(stack.pop() === (2))
>    assert(stack.pop() === (1))
>  }
>
>  test("Stack should throw NoSuchElementException if an empty stack is
> popped") {
>    val emptyStack = new Stack[String]
>    intercept[NoSuchElementException] {
>      emptyStack.pop()
>    }
>  }
>
>  test("Stack's private decorate method should place quotes around strings") {
>    val stack = new Stack[String]
>    val decorate = PrivateMethod[String]('decorate)
>    val result = stack invokePrivate decorate("hello")
>    assert(result === "\"hello\"")
>  }
> }
>
> For TestNG enthusiasts
>
> Or perhaps you've been using TestNG in Java, and you want to continue
> using it in Scala. You like the matchers DSL, but prefer the word
> "must" to "should". If this sounds like you, you can mix trait
> TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
> TestNG will be happy to run them, as will ScalaTest) that look like
> this:
>
> class StackSuite extends TestNGSuite with MustMatchers {
>
>  @Test def mustPopInLifoOrder() {
>    val stack = new Stack[Int]
>    stack.push(1)
>    stack.push(2)
>    stack.pop() must equal (2)
>    stack.pop() must equal (1)
>  }
>
>  @Test def mustBeEmptyWhenCreated() {
>    val stack = new Stack[Int]
>    stack must be ('empty)
>  }
> }
>
> For JUnit and ScalaCheck users
>
> ScalaTest also provides traits that support writing JUnit tests in
> Java, combining the benefits of using the established defacto standard
> testing tool for the Java community with the more concise, readable
> syntax of ScalaTest assertions and matchers. If you want to write
> JUnit tests in Scala, but also really like the bang for the buck you
> get by writing ScalaCheck property checks, you might mix trait
> JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
> testing trait, including the Spec, FunSuite, and TestNGSuite traits
> shown previously, to include ScalaCheck property checks among
> traditional assertions.) This would give you tests that look like:
>
> class StackSuite extends JUnit3Suite with Checkers {
>
>  def testPopsInLifoOrder() {
>    val stack = new Stack[Int]
>    stack.push(1)
>    stack.push(2)
>    assert(stack.pop() === (2))
>    assert(stack.pop() === (1))
>  }
>
>  def testIsEmptyWhenCreated() {
>    val stack = new Stack[Int]
>    assert(stack.isEmpty)
>  }
>
>  def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
> property check
>    check(
>      (list: List[Int]) => {
>        val stack = new Stack[Int]
>        for (element <- list) stack.push(element)
>        stack.elements.toList == list
>      }
>    )
>  }
> }
>
> And more...
>
> If you have some other preference, ScalaTest is designed to be
> extended, so you can create your own testing traits that look and act
> exactly as you want. In short, ScalaTest is about productivity, your
> productivity. You can mix ScalaTest traits together into whatever
> combination creates the testing tool you find the most fun and
> productive to use.
>
> Enjoy.
>
> Bill
> ---
> Bill Venners
> Artima, Inc.
> http://www.artima.com
>

Hi Stepan,

Here's my complementary answer.

I am indeed working with Bill to integrate specs into ScalaTest with the
idea that there could be a convergence on ScalaTest as an execution and
reporting plateform.

On the other hand, Bill has adopted a different approach than me on the BDD
syntax. Some differences are minor:

Example 0

"should" vs "must"

I took "should" or "can" when describing the system under specification
(sus) because it relates to informal specifications:

my system should do something
my system can have this wonderful feature

And this is indeed the vocabulary you often find in software specifications
on paper. On the other hand, when writing the code which is supposed to be
the formalization of a feature, I prefer "must" because it looks more
deterministic.

Example 1

> a must be_==(b) // Specs
> a must equal (b) // ScalaTest

The same notation could be adopted in specs by defining the "equal" matcher
as a synonym to be_==. I think it used to be there. I usually adopt the more
succinct:

a must_== b

but I could easily add a == matcher to get:

a must == (b) (note the parenthesis)

Example 2

a must beGreaterThanOrEqualTo(b) // Specs
a must be >= (b) // ScalaTest

In specs you can write "a must be_>= (b)"

Now, and this is where this is interesting, there is a major difference as
shown in Bill's example:

Example 3

map must (notHaveKey(7) and notHaveSize(8)) // specs
map must (not contain key (7) and not have size (8)) // ScalaTest

In specs, you have Matchers which can be combined with and, or, not. So if
you create a new matcher, you will get all the "logical operators" for free.
On the other hand in ScalaTest "not contains" in the above example actually
relates to a class Not having a method "contains". The great advantage of
this approach is that you can write very elegant specifications with each
word being separated. The downside of it is that you may not be able to use
"not" with your own custom matcher.

Yet, this may not be a big drawback because:

- the vocabulary actually used on a project may be largely covered by the
methods already provided by ScalaTest
- I may be wrong and there may be easy ways to extends ScalaTest easily so
that you can use your own matchers with not (Bill, can you correct me?)

That being said, I want to pursue the specs project on its own path. First
because I like it :-D and second, because I want to try out a few new ideas
for functional specifications. Or other weird ideas. For example, sometime
ago, I realized that my expectations were not providing precise enough
messages:

val list = List(1, 2, 3, 4, 5, 6)
val antepenultimate = list(list.size - 2) // wrong implementation

// this fails with " '5' is not equal to '4' "
antepenultimate must_== 4

// this fails with: " the antepenultimate element '5' is not equal to '4' "
antepenultimate aka "the antepenultimate element" must_== 4

This means that you can use "aka" (also-know-as) to specify the meaning of a
given value in an expectation.

Anyway, congratulations to Bill, he's heading towards a very solid version
1.0 of ScalaTest.

Eric.

Thank you!
I have two issues... first, the zip file contains files named :w; my windows gets confused. second, I wonder if there is a way to run these tests in IDE (I mean, in Eclipse).
-Vlad

2009/3/3 Bill Venners <bill@artima.com>

Hi All,

I'd to announce that ScalaTest 0.9.5 is out the door and ready for
download. This a rather major release that includes a matchers DSL and
enhancements to the GUI designed to improve your productivity. You can
get ScalaTest from here:

http://www.artima.com/scalatest

Here's an overview of what ScalaTest is all about, taken from its home page:
;
ScalaTest is a free, open-source testing tool for Scala and Java
programmers. It is written in Scala, and enables you to write tests in
Scala to test either Scala or Java code. It is released under the
Apache 2.0 open source license.

Because different developers take different approaches to creating
software, no single approach to testing is a good fit for everyone. In
light of this reality, ScalaTest is designed to facilitate different
styles of testing. ScalaTest provides several traits that you can mix
together into whatever combination makes you feel the most productive.

For behavior-driven developers

For example, if you like the behavior-driven development style of
testing, in which tests are viewed as informal specifications of the
code under test, you might mix trait Spec with trait ShouldMatchers.
Your tests would look something like:

class StackSpec extends Spec with ShouldMatchers {

 describe("A Stack") {

   it("should pop values in last-in-first-out order") {
     val stack = new Stack[Int]
     stack.push(1)
     stack.push(2)
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }

   it("should be empty when created") {
     val stack = new Stack[Int]
     stack should be ('empty)
   }
 }
}

When you run this Spec its output will be structured as an
easy-to-read informal specification of the Stack it tests. ScalaTest
can format the specification output in its GUI or in text. In text, it
would look like:

A Stack
- should pop values in last-in-first-out order
- should be empty when created

ScalaTest's ShouldMatchers provide an elegant DSL for expressing
assertions, which can make the code more readable and failure messages
easier to understand. Some other examples are:

map should (contain key ("one") and not contain value (10))
result should be >= (0)
book should have (title ("Programming in Scala"))
tempFile should not be a ('directory)
quotient should be (1.0 plusOrMinus 0.2)

For more traditional testers

As elegant and readable as the matcher expressions may seem to some,
you may find them too verbose for your taste. You may also prefer to
think of tests as, well, tests rather than as specifications, and you
also may find you often need to test private methods. If this
describes you, you might mix trait FunSuite with trait
PrivateMethodTester, yielding tests that look like:

class StackSuite extends FunSuite with PrivateMethodTester {

 test("Stack should pop values in last-in-first-out order") {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 test("Stack should throw NoSuchElementException if an empty stack is
popped") {
   val emptyStack = new Stack[String]
   intercept[NoSuchElementException] {
     emptyStack.pop()
   }
 }

 test("Stack's private decorate method should place quotes around strings") {
   val stack = new Stack[String]
   val decorate = PrivateMethod[String]('decorate)
   val result = stack invokePrivate decorate("hello")
   assert(result === "\"hello\"")
 }
}

For TestNG enthusiasts

Or perhaps you've been using TestNG in Java, and you want to continue
using it in Scala. You like the matchers DSL, but prefer the word
"must" to "should". If this sounds like you, you can mix trait
TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
TestNG will be happy to run them, as will ScalaTest) that look like
this:

class StackSuite extends TestNGSuite with MustMatchers {

 @Test def mustPopInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   stack.pop() must equal (2)
   stack.pop() must equal (1)
 }

 @Test def mustBeEmptyWhenCreated() {
   val stack = new Stack[Int]
   stack must be ('empty)
 }
}

For JUnit and ScalaCheck users

ScalaTest also provides traits that support writing JUnit tests in
Java, combining the benefits of using the established defacto standard
testing tool for the Java community with the more concise, readable
syntax of ScalaTest assertions and matchers. If you want to write
JUnit tests in Scala, but also really like the bang for the buck you
get by writing ScalaCheck property checks, you might mix trait
JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
testing trait, including the Spec, FunSuite, and TestNGSuite traits
shown previously, to include ScalaCheck property checks among
traditional assertions.) This would give you tests that look like:

class StackSuite extends JUnit3Suite with Checkers {

 def testPopsInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 def testIsEmptyWhenCreated() {
   val stack = new Stack[Int]
   assert(stack.isEmpty)
 }

 def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
property check
   check(
     (list: List[Int]) => {
       val stack = new Stack[Int]
       for (element <- list) stack.push(element)
       stack.elements.toList == list
     }
   )
 }
}

And more...

If you have some other preference, ScalaTest is designed to be
extended, so you can create your own testing traits that look and act
exactly as you want. In short, ScalaTest is about productivity, your
productivity. You can mix ScalaTest traits together into whatever
combination creates the testing tool you find the most fun and
productive to use.

Enjoy.

Bill
---
Bill Venners
Artima, Inc.
http://www.artima.com

Eric, Bill, thank you for answers.

S.

On Thu, Mar 5, 2009 at 10:02, Eric Torreborre wrote:
>
> Hi Stepan,
>
> Here's my complementary answer.
>
> I am indeed working with Bill to integrate specs into ScalaTest with the
> idea that there could be a convergence on ScalaTest as an execution and
> reporting plateform.
>
> On the other hand, Bill has adopted a different approach than me on the BDD
> syntax. Some differences are minor:
>
> Example 0
>
> "should" vs "must"
>
> I took "should" or "can" when describing the system under specification
> (sus) because it relates to informal specifications:
>
> my system should do something
> my system can have this wonderful feature
>
> And this is indeed the vocabulary you often find in software specifications
> on paper. On the other hand, when writing the code which is supposed to be
> the formalization of a feature, I prefer "must" because it looks more
> deterministic.
>
> Example 1
>
>> a must be_==(b) // Specs
>> a must equal (b) // ScalaTest
>
> The same notation could be adopted in specs by defining the "equal" matcher
> as a synonym to be_==. I think it used to be there. I usually adopt the more
> succinct:
>
> a must_== b
>
> but I could easily add a == matcher to get:
>
> a must == (b) (note the parenthesis)
>
> Example 2
>
> a must beGreaterThanOrEqualTo(b) // Specs
> a must be >= (b) // ScalaTest
>
> In specs you can write "a must be_>= (b)"
>
> Now, and this is where this is interesting, there is a major difference as
> shown in Bill's example:
>
> Example 3
>
> map must (notHaveKey(7) and notHaveSize(8))  // specs
> map must (not contain key (7) and not have size (8))  // ScalaTest
>
> In specs, you have Matchers which can be combined with and, or, not. So if
> you create a new matcher, you will get all the "logical operators" for free.
> On the other hand in ScalaTest "not contains" in the above example actually
> relates to a class Not having a method "contains". The great advantage of
> this approach is that you can write very elegant specifications with each
> word being separated. The downside of it is that you may not be able to use
> "not" with your own custom matcher.
>
> Yet, this may not be a big drawback because:
>
> - the vocabulary actually used on a project may be largely covered by the
> methods already provided by ScalaTest
> - I may be wrong and there may be easy ways to extends ScalaTest easily so
> that you can use your own matchers with not (Bill, can you correct me?)
>
> That being said, I want to pursue the specs project on its own path. First
> because I like it :-D and second, because I want to try out a few new ideas
> for functional specifications. Or other weird ideas. For example, sometime
> ago, I realized that my expectations were not providing precise enough
> messages:
>
> val list = List(1, 2, 3, 4, 5, 6)
> val antepenultimate = list(list.size - 2) // wrong implementation
>
> // this fails with " '5' is not equal to '4' "
> antepenultimate must_== 4
>
> // this fails with: " the antepenultimate element '5' is not equal to '4' "
> antepenultimate aka "the antepenultimate element" must_== 4
>
> This means that you can use "aka" (also-know-as) to specify the meaning of a
> given value in an expectation.
>
> Anyway, congratulations to Bill, he's heading towards a very solid version
> 1.0 of ScalaTest.
>
> Eric.
> --
> View this message in context: http://www.nabble.com/ScalaTest-0.9.5-released%21-tp22321488p22346253.html
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

Oh, and an additional "HELP!" scream.
It would be nice to have somewhere on the web simple, detailed list of steps to make to make my tests run. I can write tests, I can't figure out how to either integrate them in Eclipse or run them in command line. The only sample command line on the page refers to the main SuiteSuite, it does not seem to be applicable to junit/samples/JUnitSampleSuite... or is it?
-Vlad

2009/3/5 Vlad Patryshev <vpatryshev@gmail.com>

Thank you!
I have two issues... first, the zip file contains files named :w; my windows gets confused. second, I wonder if there is a way to run these tests in IDE (I mean, in Eclipse).
-Vlad

2009/3/3 Bill Venners <bill@artima.com>

Hi All,

I'd to announce that ScalaTest 0.9.5 is out the door and ready for
download. This a rather major release that includes a matchers DSL and
enhancements to the GUI designed to improve your productivity. You can
get ScalaTest from here:

http://www.artima.com/scalatest

Here's an overview of what ScalaTest is all about, taken from its home page:
;
ScalaTest is a free, open-source testing tool for Scala and Java
programmers. It is written in Scala, and enables you to write tests in
Scala to test either Scala or Java code. It is released under the
Apache 2.0 open source license.

Because different developers take different approaches to creating
software, no single approach to testing is a good fit for everyone. In
light of this reality, ScalaTest is designed to facilitate different
styles of testing. ScalaTest provides several traits that you can mix
together into whatever combination makes you feel the most productive.

For behavior-driven developers

For example, if you like the behavior-driven development style of
testing, in which tests are viewed as informal specifications of the
code under test, you might mix trait Spec with trait ShouldMatchers.
Your tests would look something like:

class StackSpec extends Spec with ShouldMatchers {

 describe("A Stack") {

   it("should pop values in last-in-first-out order") {
     val stack = new Stack[Int]
     stack.push(1)
     stack.push(2)
     stack.pop() should equal (2)
     stack.pop() should equal (1)
   }

   it("should be empty when created") {
     val stack = new Stack[Int]
     stack should be ('empty)
   }
 }
}

When you run this Spec its output will be structured as an
easy-to-read informal specification of the Stack it tests. ScalaTest
can format the specification output in its GUI or in text. In text, it
would look like:

A Stack
- should pop values in last-in-first-out order
- should be empty when created

ScalaTest's ShouldMatchers provide an elegant DSL for expressing
assertions, which can make the code more readable and failure messages
easier to understand. Some other examples are:

map should (contain key ("one") and not contain value (10))
result should be >= (0)
book should have (title ("Programming in Scala"))
tempFile should not be a ('directory)
quotient should be (1.0 plusOrMinus 0.2)

For more traditional testers

As elegant and readable as the matcher expressions may seem to some,
you may find them too verbose for your taste. You may also prefer to
think of tests as, well, tests rather than as specifications, and you
also may find you often need to test private methods. If this
describes you, you might mix trait FunSuite with trait
PrivateMethodTester, yielding tests that look like:

class StackSuite extends FunSuite with PrivateMethodTester {

 test("Stack should pop values in last-in-first-out order") {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 test("Stack should throw NoSuchElementException if an empty stack is
popped") {
   val emptyStack = new Stack[String]
   intercept[NoSuchElementException] {
     emptyStack.pop()
   }
 }

 test("Stack's private decorate method should place quotes around strings") {
   val stack = new Stack[String]
   val decorate = PrivateMethod[String]('decorate)
   val result = stack invokePrivate decorate("hello")
   assert(result === "\"hello\"")
 }
}

For TestNG enthusiasts

Or perhaps you've been using TestNG in Java, and you want to continue
using it in Scala. You like the matchers DSL, but prefer the word
"must" to "should". If this sounds like you, you can mix trait
TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
TestNG will be happy to run them, as will ScalaTest) that look like
this:

class StackSuite extends TestNGSuite with MustMatchers {

 @Test def mustPopInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   stack.pop() must equal (2)
   stack.pop() must equal (1)
 }

 @Test def mustBeEmptyWhenCreated() {
   val stack = new Stack[Int]
   stack must be ('empty)
 }
}

For JUnit and ScalaCheck users

ScalaTest also provides traits that support writing JUnit tests in
Java, combining the benefits of using the established defacto standard
testing tool for the Java community with the more concise, readable
syntax of ScalaTest assertions and matchers. If you want to write
JUnit tests in Scala, but also really like the bang for the buck you
get by writing ScalaCheck property checks, you might mix trait
JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
testing trait, including the Spec, FunSuite, and TestNGSuite traits
shown previously, to include ScalaCheck property checks among
traditional assertions.) This would give you tests that look like:

class StackSuite extends JUnit3Suite with Checkers {

 def testPopsInLifoOrder() {
   val stack = new Stack[Int]
   stack.push(1)
   stack.push(2)
   assert(stack.pop() === (2))
   assert(stack.pop() === (1))
 }

 def testIsEmptyWhenCreated() {
   val stack = new Stack[Int]
   assert(stack.isEmpty)
 }

 def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
property check
   check(
     (list: List[Int]) => {
       val stack = new Stack[Int]
       for (element <- list) stack.push(element)
       stack.elements.toList == list
     }
   )
 }
}

And more...

If you have some other preference, ScalaTest is designed to be
extended, so you can create your own testing traits that look and act
exactly as you want. In short, ScalaTest is about productivity, your
productivity. You can mix ScalaTest traits together into whatever
combination creates the testing tool you find the most fun and
productive to use.

Enjoy.

Bill
---
Bill Venners
Artima, Inc.
http://www.artima.com

--
Thanks,
-Vlad

Hi Vlad,

The detailed description on running from the command line is in the
ScalaDoc for org.scalatest.tools.Runner, which is here:

http://www.artima.com/scalatest/doc-0.9.5/org/scalatest/tools/Runner$object.html

Sorry about the :w file. One of those vi slip ups. You can delete it.
And of course consider the :w file deprecated. It will be removed from
the next release of ScalaTest!

Bill

On Thu, Mar 5, 2009 at 3:18 PM, Vlad Patryshev wrote:
> Oh, and an additional "HELP!" scream.
> It would be nice to have somewhere on the web simple, detailed list of steps
> to make to make my tests run. I can write tests, I can't figure out how to
> either integrate them in Eclipse or run them in command line. The only
> sample command line on the page refers to the main SuiteSuite, it does not
> seem to be applicable to junit/samples/JUnitSampleSuite... or is it?
> -Vlad
>
> 2009/3/5 Vlad Patryshev
>>
>> Thank you!
>> I have two issues... first, the zip file contains files named :w; my
>> windows gets confused. second, I wonder if there is a way to run these tests
>> in IDE (I mean, in Eclipse).
>> -Vlad
>>
>> 2009/3/3 Bill Venners
>>>
>>> Hi All,
>>>
>>> I'd to announce that ScalaTest 0.9.5 is out the door and ready for
>>> download. This a rather major release that includes a matchers DSL and
>>> enhancements to the GUI designed to improve your productivity. You can
>>> get ScalaTest from here:
>>>
>>> http://www.artima.com/scalatest
>>>
>>> Here's an overview of what ScalaTest is all about, taken from its home
>>> page:
>>> ;
>>> ScalaTest is a free, open-source testing tool for Scala and Java
>>> programmers. It is written in Scala, and enables you to write tests in
>>> Scala to test either Scala or Java code. It is released under the
>>> Apache 2.0 open source license.
>>>
>>> Because different developers take different approaches to creating
>>> software, no single approach to testing is a good fit for everyone. In
>>> light of this reality, ScalaTest is designed to facilitate different
>>> styles of testing. ScalaTest provides several traits that you can mix
>>> together into whatever combination makes you feel the most productive.
>>>
>>> For behavior-driven developers
>>>
>>> For example, if you like the behavior-driven development style of
>>> testing, in which tests are viewed as informal specifications of the
>>> code under test, you might mix trait Spec with trait ShouldMatchers.
>>> Your tests would look something like:
>>>
>>> class StackSpec extends Spec with ShouldMatchers {
>>>
>>>  describe("A Stack") {
>>>
>>>    it("should pop values in last-in-first-out order") {
>>>      val stack = new Stack[Int]
>>>      stack.push(1)
>>>      stack.push(2)
>>>      stack.pop() should equal (2)
>>>      stack.pop() should equal (1)
>>>    }
>>>
>>>    it("should be empty when created") {
>>>      val stack = new Stack[Int]
>>>      stack should be ('empty)
>>>    }
>>>  }
>>> }
>>>
>>> When you run this Spec its output will be structured as an
>>> easy-to-read informal specification of the Stack it tests. ScalaTest
>>> can format the specification output in its GUI or in text. In text, it
>>> would look like:
>>>
>>> A Stack
>>> - should pop values in last-in-first-out order
>>> - should be empty when created
>>>
>>> ScalaTest's ShouldMatchers provide an elegant DSL for expressing
>>> assertions, which can make the code more readable and failure messages
>>> easier to understand. Some other examples are:
>>>
>>> map should (contain key ("one") and not contain value (10))
>>> result should be >= (0)
>>> book should have (title ("Programming in Scala"))
>>> tempFile should not be a ('directory)
>>> quotient should be (1.0 plusOrMinus 0.2)
>>>
>>> For more traditional testers
>>>
>>> As elegant and readable as the matcher expressions may seem to some,
>>> you may find them too verbose for your taste. You may also prefer to
>>> think of tests as, well, tests rather than as specifications, and you
>>> also may find you often need to test private methods. If this
>>> describes you, you might mix trait FunSuite with trait
>>> PrivateMethodTester, yielding tests that look like:
>>>
>>> class StackSuite extends FunSuite with PrivateMethodTester {
>>>
>>>  test("Stack should pop values in last-in-first-out order") {
>>>    val stack = new Stack[Int]
>>>    stack.push(1)
>>>    stack.push(2)
>>>    assert(stack.pop() === (2))
>>>    assert(stack.pop() === (1))
>>>  }
>>>
>>>  test("Stack should throw NoSuchElementException if an empty stack is
>>> popped") {
>>>    val emptyStack = new Stack[String]
>>>    intercept[NoSuchElementException] {
>>>      emptyStack.pop()
>>>    }
>>>  }
>>>
>>>  test("Stack's private decorate method should place quotes around
>>> strings") {
>>>    val stack = new Stack[String]
>>>    val decorate = PrivateMethod[String]('decorate)
>>>    val result = stack invokePrivate decorate("hello")
>>>    assert(result === "\"hello\"")
>>>  }
>>> }
>>>
>>> For TestNG enthusiasts
>>>
>>> Or perhaps you've been using TestNG in Java, and you want to continue
>>> using it in Scala. You like the matchers DSL, but prefer the word
>>> "must" to "should". If this sounds like you, you can mix trait
>>> TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
>>> TestNG will be happy to run them, as will ScalaTest) that look like
>>> this:
>>>
>>> class StackSuite extends TestNGSuite with MustMatchers {
>>>
>>>  @Test def mustPopInLifoOrder() {
>>>    val stack = new Stack[Int]
>>>    stack.push(1)
>>>    stack.push(2)
>>>    stack.pop() must equal (2)
>>>    stack.pop() must equal (1)
>>>  }
>>>
>>>  @Test def mustBeEmptyWhenCreated() {
>>>    val stack = new Stack[Int]
>>>    stack must be ('empty)
>>>  }
>>> }
>>>
>>> For JUnit and ScalaCheck users
>>>
>>> ScalaTest also provides traits that support writing JUnit tests in
>>> Java, combining the benefits of using the established defacto standard
>>> testing tool for the Java community with the more concise, readable
>>> syntax of ScalaTest assertions and matchers. If you want to write
>>> JUnit tests in Scala, but also really like the bang for the buck you
>>> get by writing ScalaCheck property checks, you might mix trait
>>> JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
>>> testing trait, including the Spec, FunSuite, and TestNGSuite traits
>>> shown previously, to include ScalaCheck property checks among
>>> traditional assertions.) This would give you tests that look like:
>>>
>>> class StackSuite extends JUnit3Suite with Checkers {
>>>
>>>  def testPopsInLifoOrder() {
>>>    val stack = new Stack[Int]
>>>    stack.push(1)
>>>    stack.push(2)
>>>    assert(stack.pop() === (2))
>>>    assert(stack.pop() === (1))
>>>  }
>>>
>>>  def testIsEmptyWhenCreated() {
>>>    val stack = new Stack[Int]
>>>    assert(stack.isEmpty)
>>>  }
>>>
>>>  def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
>>> property check
>>>    check(
>>>      (list: List[Int]) => {
>>>        val stack = new Stack[Int]
>>>        for (element <- list) stack.push(element)
>>>        stack.elements.toList == list
>>>      }
>>>    )
>>>  }
>>> }
>>>
>>> And more...
>>>
>>> If you have some other preference, ScalaTest is designed to be
>>> extended, so you can create your own testing traits that look and act
>>> exactly as you want. In short, ScalaTest is about productivity, your
>>> productivity. You can mix ScalaTest traits together into whatever
>>> combination creates the testing tool you find the most fun and
>>> productive to use.
>>>
>>> Enjoy.
>>>
>>> Bill
>>> ---
>>> Bill Venners
>>> Artima, Inc.
>>> http://www.artima.com
>>
>>
>
>
>
> --
> Thanks,
> -Vlad
>

Hi Eric,

> Example 3
>
> map must (notHaveKey(7) and notHaveSize(8))  // specs
> map must (not contain key (7) and not have size (8))  // ScalaTest
>
> In specs, you have Matchers which can be combined with and, or, not. So if
> you create a new matcher, you will get all the "logical operators" for free.
> On the other hand in ScalaTest "not contains" in the above example actually
> relates to a class Not having a method "contains". The great advantage of
> this approach is that you can write very elegant specifications with each
> word being separated. The downside of it is that you may not be able to use
> "not" with your own custom matcher.
>
> Yet, this may not be a big drawback because:
>
> - the vocabulary actually used on a project may be largely covered by the
> methods already provided by ScalaTest
> - I may be wrong and there may be easy ways to extends ScalaTest easily so
> that you can use your own matchers with not (Bill, can you correct me?)
>
Yes, you can create your own ScalaTest matchers. Perhaps one of the
design tradeoffs here is that there are 4 different kinds of matchers
in ScalaTest, because you can create a regular matcher, which goes
after should/must. But you can create a BeMatcher that goes after be.
There are also two kinds of property matchers, one that goes after be
and the other after have. The property matchers are a type safe way to
do property verifications, which you can do dynamically by passing in
symbols. I figure the property matchers are a good candidate for code
generation, because they could be generated from looking at the
production classes.

You can also use custom matchers with not, but you will often need
parens. Whenever you sometimes need parens I've recommended you always
use them.

So some examples, you could create a Matcher[java.io.File] named exist
that lets you say:

myFile should exist

But to use not you need to use parens:

myOtherFile should not (exist)

You could make a BeMatcher[Int] named odd that lets you say:

myInt should be (odd)

To check a boolean property, you can make a
BePropertyMatcher[java.io.File] named file that lets you say:

tempFile should be a (file)

To check an arbitrary property, you can make a
HavePropertyMatcher[Book] named title that let's you say:

book should have (title ("Moby, Dick"))

There are links to the documentation for each of these off of the main
documentation for matchers:

http://www.artima.com/scalatest/doc-0.9.5/org/scalatest/matchers/ShouldM...

Thanks.

Bill

Hi Vlad,

You also asked about IDE support. Right now I just invoke from the
command line, by making a "Run configuration" in the IDE that invokes
ScalaTest passing in the appropriate command line args. One way people
have been running directly in IDEs is to use TestNGSuite, which allows
IDEs to run them as TestNG tests. You could also do this with
JUnit3Suite, but you'd have to use JUnit 3's syntax. We've working
this week on a JUnitRunner that you can put in a @RunWith annotation
on any kind of Suite, which would enable you to use the IDE's JUnit
support. And the plan is to eventually have direct IDE support for
IntelliJ, NetBeans, and Eclipse.

Bill

On Thu, Mar 5, 2009 at 11:44 AM, Vlad Patryshev wrote:
> Thank you!
> I have two issues... first, the zip file contains files named :w; my windows
> gets confused. second, I wonder if there is a way to run these tests in IDE
> (I mean, in Eclipse).
> -Vlad
>
> 2009/3/3 Bill Venners
>>
>> Hi All,
>>
>> I'd to announce that ScalaTest 0.9.5 is out the door and ready for
>> download. This a rather major release that includes a matchers DSL and
>> enhancements to the GUI designed to improve your productivity. You can
>> get ScalaTest from here:
>>
>> http://www.artima.com/scalatest
>>
>> Here's an overview of what ScalaTest is all about, taken from its home
>> page:
>> ;
>> ScalaTest is a free, open-source testing tool for Scala and Java
>> programmers. It is written in Scala, and enables you to write tests in
>> Scala to test either Scala or Java code. It is released under the
>> Apache 2.0 open source license.
>>
>> Because different developers take different approaches to creating
>> software, no single approach to testing is a good fit for everyone. In
>> light of this reality, ScalaTest is designed to facilitate different
>> styles of testing. ScalaTest provides several traits that you can mix
>> together into whatever combination makes you feel the most productive.
>>
>> For behavior-driven developers
>>
>> For example, if you like the behavior-driven development style of
>> testing, in which tests are viewed as informal specifications of the
>> code under test, you might mix trait Spec with trait ShouldMatchers.
>> Your tests would look something like:
>>
>> class StackSpec extends Spec with ShouldMatchers {
>>
>>  describe("A Stack") {
>>
>>    it("should pop values in last-in-first-out order") {
>>      val stack = new Stack[Int]
>>      stack.push(1)
>>      stack.push(2)
>>      stack.pop() should equal (2)
>>      stack.pop() should equal (1)
>>    }
>>
>>    it("should be empty when created") {
>>      val stack = new Stack[Int]
>>      stack should be ('empty)
>>    }
>>  }
>> }
>>
>> When you run this Spec its output will be structured as an
>> easy-to-read informal specification of the Stack it tests. ScalaTest
>> can format the specification output in its GUI or in text. In text, it
>> would look like:
>>
>> A Stack
>> - should pop values in last-in-first-out order
>> - should be empty when created
>>
>> ScalaTest's ShouldMatchers provide an elegant DSL for expressing
>> assertions, which can make the code more readable and failure messages
>> easier to understand. Some other examples are:
>>
>> map should (contain key ("one") and not contain value (10))
>> result should be >= (0)
>> book should have (title ("Programming in Scala"))
>> tempFile should not be a ('directory)
>> quotient should be (1.0 plusOrMinus 0.2)
>>
>> For more traditional testers
>>
>> As elegant and readable as the matcher expressions may seem to some,
>> you may find them too verbose for your taste. You may also prefer to
>> think of tests as, well, tests rather than as specifications, and you
>> also may find you often need to test private methods. If this
>> describes you, you might mix trait FunSuite with trait
>> PrivateMethodTester, yielding tests that look like:
>>
>> class StackSuite extends FunSuite with PrivateMethodTester {
>>
>>  test("Stack should pop values in last-in-first-out order") {
>>    val stack = new Stack[Int]
>>    stack.push(1)
>>    stack.push(2)
>>    assert(stack.pop() === (2))
>>    assert(stack.pop() === (1))
>>  }
>>
>>  test("Stack should throw NoSuchElementException if an empty stack is
>> popped") {
>>    val emptyStack = new Stack[String]
>>    intercept[NoSuchElementException] {
>>      emptyStack.pop()
>>    }
>>  }
>>
>>  test("Stack's private decorate method should place quotes around
>> strings") {
>>    val stack = new Stack[String]
>>    val decorate = PrivateMethod[String]('decorate)
>>    val result = stack invokePrivate decorate("hello")
>>    assert(result === "\"hello\"")
>>  }
>> }
>>
>> For TestNG enthusiasts
>>
>> Or perhaps you've been using TestNG in Java, and you want to continue
>> using it in Scala. You like the matchers DSL, but prefer the word
>> "must" to "should". If this sounds like you, you can mix trait
>> TestNGSuite with trait MustMatchers, yielding TestNG tests (i.e.,
>> TestNG will be happy to run them, as will ScalaTest) that look like
>> this:
>>
>> class StackSuite extends TestNGSuite with MustMatchers {
>>
>>  @Test def mustPopInLifoOrder() {
>>    val stack = new Stack[Int]
>>    stack.push(1)
>>    stack.push(2)
>>    stack.pop() must equal (2)
>>    stack.pop() must equal (1)
>>  }
>>
>>  @Test def mustBeEmptyWhenCreated() {
>>    val stack = new Stack[Int]
>>    stack must be ('empty)
>>  }
>> }
>>
>> For JUnit and ScalaCheck users
>>
>> ScalaTest also provides traits that support writing JUnit tests in
>> Java, combining the benefits of using the established defacto standard
>> testing tool for the Java community with the more concise, readable
>> syntax of ScalaTest assertions and matchers. If you want to write
>> JUnit tests in Scala, but also really like the bang for the buck you
>> get by writing ScalaCheck property checks, you might mix trait
>> JUnit3Suite with trait Checkers. (Trait Checkers can be mixed into any
>> testing trait, including the Spec, FunSuite, and TestNGSuite traits
>> shown previously, to include ScalaCheck property checks among
>> traditional assertions.) This would give you tests that look like:
>>
>> class StackSuite extends JUnit3Suite with Checkers {
>>
>>  def testPopsInLifoOrder() {
>>    val stack = new Stack[Int]
>>    stack.push(1)
>>    stack.push(2)
>>    assert(stack.pop() === (2))
>>    assert(stack.pop() === (1))
>>  }
>>
>>  def testIsEmptyWhenCreated() {
>>    val stack = new Stack[Int]
>>    assert(stack.isEmpty)
>>  }
>>
>>  def testElementsHasAllObjectsPushedInOrder() { // uses a ScalaCheck
>> property check
>>    check(
>>      (list: List[Int]) => {
>>        val stack = new Stack[Int]
>>        for (element <- list) stack.push(element)
>>        stack.elements.toList == list
>>      }
>>    )
>>  }
>> }
>>
>> And more...
>>
>> If you have some other preference, ScalaTest is designed to be
>> extended, so you can create your own testing traits that look and act
>> exactly as you want. In short, ScalaTest is about productivity, your
>> productivity. You can mix ScalaTest traits together into whatever
>> combination creates the testing tool you find the most fun and
>> productive to use.
>>
>> Enjoy.
>>
>> Bill
>> ---
>> Bill Venners
>> Artima, Inc.
>> http://www.artima.com
>
>
>