[ANN] New specs release: 1.4.3

Great news, Eric!

Just as a shameless promotional, if you're using Scala and you haven't tried Specs yet, you're missing out!  It's really BDD the way it was meant to be done: simple, intuitive and very powerful.  I can't say that it makes testing fun, but it certainly eases the pain.

Daniel

On Wed, Feb 11, 2009 at 7:02 PM, Eric Torreborre <etorreborre@yahoo.com> wrote:

Hi,

I would like to announce a new specs release, 1.4.3.

This release fixes the following issues:

-issue 50: subexamples reporting
-issue 51, 53: "behave like" is not working
-issue 55: beIn, notBeIn restrictions
-ScalaCheck's "forAll" function was hidden by a function with the same name
in the ScalaCheckFunctions trait. Fixing this issue now allows to fix the
deprecation warnings from ScalaCheck 1.5 when using the "property" function.
-timer displaying a total time of 0 for composed specifications executed in
the Console

And introduces few new features:

-a "-xOnly" or "--failedOnly" option to only display failures and errors in
the console
-a beOneOf matcher
-a containMatchOnlyOnce matcher

I also get the opportunity of this release to present the specs library once
more for Scala newcomers on the list ;-)

specs is a Behaviour-Driven-Design framework which provides:

- a simple and typed language to create software specifications:

object helloWorld extends Specification {
 "'hello world' has 11 characters" in {
    "hello world".size must beEqualTo(11)
 }
 "'hello world' matches 'h.* w.*'" in {
    "hello world" must beMatching("h.* w.*")
 }
}


- lots of matchers to specify code properties:

 "myString" must beMatching("Str.*")

 // or to specify xml pieces using XPath-like operators:
 <c><d></d></c>  must \\("c").\("d")

- an integration with JUnit to so that you can run and report your tests
using your existing infrastructure

- an easy way to specify combinatorial properties through an integration
with ScalaCheck:

// generates 500 different mail addresses
mailAddresses must pass { address =>
 address must beMatching(companyPattern)
}

- an integration with jMock2

- and much, much more,... See the
http://code.google.com/p/specs/wiki/UserGuide User Guide .

Happy specs!

Eric.
--
View this message in context: http://www.nabble.com/-ANN--New-specs-release%3A-1.4.3-tp21967956p21967956.html
Sent from the Scala - Tools mailing list archive at Nabble.com.

Specs is great. It is only surpassed by parser combinators as
examples of DSLs in Scala, and very useful. I found it a bit
confusing when I tried to create reusable specifications, largely
because I didn't know that that was what I was doing. iow:

class Foo extends Specification { bar("Foo") }
def bar(name: String) = name.length < 100 mustBe true

This has no effect. I'm not sure there's much that Eric can do about
this to detect it etc. I think it's a limitation of the approach he
took, and I'm not sure I can think of another approach that would be
as readable and flexible.

The correct code, for completeness:

class Foo extends Specification { "Foo's name" isSpecifiedBy bar }

def bar(name: String) = new Specification { name.length < 100 mustBe true }

2009/2/12 Daniel Spiewak :
> Great news, Eric!
>
> Just as a shameless promotional, if you're using Scala and you haven't tried
> Specs yet, you're missing out! It's really BDD the way it was meant to be
> done: simple, intuitive and very powerful. I can't say that it makes
> testing fun, but it certainly eases the pain.
>
> Daniel
>
> On Wed, Feb 11, 2009 at 7:02 PM, Eric Torreborre
> wrote:
>>
>> Hi,
>>
>> I would like to announce a new specs release, 1.4.3.
>>
>> This release fixes the following issues:
>>
>> -issue 50: subexamples reporting
>> -issue 51, 53: "behave like" is not working
>> -issue 55: beIn, notBeIn restrictions
>> -ScalaCheck's "forAll" function was hidden by a function with the same
>> name
>> in the ScalaCheckFunctions trait. Fixing this issue now allows to fix the
>> deprecation warnings from ScalaCheck 1.5 when using the "property"
>> function.
>> -timer displaying a total time of 0 for composed specifications executed
>> in
>> the Console
>>
>> And introduces few new features:
>>
>> -a "-xOnly" or "--failedOnly" option to only display failures and errors
>> in
>> the console
>> -a beOneOf matcher
>> -a containMatchOnlyOnce matcher
>>
>> I also get the opportunity of this release to present the specs library
>> once
>> more for Scala newcomers on the list ;-)
>>
>> specs is a Behaviour-Driven-Design framework which provides:
>>
>> - a simple and typed language to create software specifications:
>>
>> object helloWorld extends Specification {
>> "'hello world' has 11 characters" in {
>> "hello world".size must beEqualTo(11)
>> }
>> "'hello world' matches 'h.* w.*'" in {
>> "hello world" must beMatching("h.* w.*")
>> }
>> }
>>
>>
>> - lots of matchers to specify code properties:
>>
>> "myString" must beMatching("Str.*")
>>
>> // or to specify xml pieces using XPath-like operators:
>> must \\("c").\("d")
>>
>> - an integration with JUnit to so that you can run and report your tests
>> using your existing infrastructure
>>
>> - an easy way to specify combinatorial properties through an integration
>> with ScalaCheck:
>>
>> // generates 500 different mail addresses
>> mailAddresses must pass { address =>
>> address must beMatching(companyPattern)
>> }
>>
>> - an integration with jMock2
>>
>> - and much, much more,... See the
>> http://code.google.com/p/specs/wiki/UserGuide User Guide .
>>
>> Happy specs!
>>
>> Eric.
>> --
>> View this message in context:
>> http://www.nabble.com/-ANN--New-specs-release%3A-1.4.3-tp21967956p219679...
>> Sent from the Scala - Tools mailing list archive at Nabble.com.
>>
>
>

This is because of the way in which Specs defines, well, specs.  Specifications are executed lazily, and assertions fall under specifications.  The isSpecifiedBy forces the evaluation because it associates bar with a top-level spec.  Eric will have to answer why it is designed this way, I only know that it is the way it is.  :-)

Daniel

On Thu, Feb 12, 2009 at 12:45 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Specs is great.  It is only surpassed by parser combinators as
examples of DSLs in Scala, and very useful.  I found it a bit
confusing when I tried to create reusable specifications, largely
because I didn't know that that was what I was doing.  iow:

class Foo extends Specification { bar("Foo") }
def bar(name: String) = name.length < 100 mustBe true

This has no effect.  I'm not sure there's much that Eric can do about
this to detect it etc.  I think it's a limitation of the approach he
took, and I'm not sure I can think of another approach that would be
as readable and flexible.

The correct code, for completeness:

class Foo extends Specification { "Foo's name" isSpecifiedBy bar }

def bar(name: String) = new Specification { name.length < 100 mustBe true }

2009/2/12 Daniel Spiewak <djspiewak@gmail.com>:
> Great news, Eric!
>
> Just as a shameless promotional, if you're using Scala and you haven't tried
> Specs yet, you're missing out!  It's really BDD the way it was meant to be
> done: simple, intuitive and very powerful.  I can't say that it makes
> testing fun, but it certainly eases the pain.
>
> Daniel
>
> On Wed, Feb 11, 2009 at 7:02 PM, Eric Torreborre <etorreborre@yahoo.com>
> wrote:
>>
>> Hi,
>>
>> I would like to announce a new specs release, 1.4.3.
>>
>> This release fixes the following issues:
>>
>> -issue 50: subexamples reporting
>> -issue 51, 53: "behave like" is not working
>> -issue 55: beIn, notBeIn restrictions
>> -ScalaCheck's "forAll" function was hidden by a function with the same
>> name
>> in the ScalaCheckFunctions trait. Fixing this issue now allows to fix the
>> deprecation warnings from ScalaCheck 1.5 when using the "property"
>> function.
>> -timer displaying a total time of 0 for composed specifications executed
>> in
>> the Console
>>
>> And introduces few new features:
>>
>> -a "-xOnly" or "--failedOnly" option to only display failures and errors
>> in
>> the console
>> -a beOneOf matcher
>> -a containMatchOnlyOnce matcher
>>
>> I also get the opportunity of this release to present the specs library
>> once
>> more for Scala newcomers on the list ;-)
>>
>> specs is a Behaviour-Driven-Design framework which provides:
>>
>> - a simple and typed language to create software specifications:
>>
>> object helloWorld extends Specification {
>>  "'hello world' has 11 characters" in {
>>     "hello world".size must beEqualTo(11)
>>  }
>>  "'hello world' matches 'h.* w.*'" in {
>>     "hello world" must beMatching("h.* w.*")
>>  }
>> }
>>
>>
>> - lots of matchers to specify code properties:
>>
>>  "myString" must beMatching("Str.*")
>>
>>  // or to specify xml pieces using XPath-like operators:
>>  <c><d></d></c>  must \\("c").\("d")
>>
>> - an integration with JUnit to so that you can run and report your tests
>> using your existing infrastructure
>>
>> - an easy way to specify combinatorial properties through an integration
>> with ScalaCheck:
>>
>> // generates 500 different mail addresses
>> mailAddresses must pass { address =>
>>  address must beMatching(companyPattern)
>> }
>>
>> - an integration with jMock2
>>
>> - and much, much more,... See the
>> http://code.google.com/p/specs/wiki/UserGuide User Guide .
>>
>> Happy specs!
>>
>> Eric.
>> --
>> View this message in context:
>> http://www.nabble.com/-ANN--New-specs-release%3A-1.4.3-tp21967956p21967956.html
>> Sent from the Scala - Tools mailing list archive at Nabble.com.
>>
>
>

Hi Ricky,

Yes, the way specs is designed, you need a "place" where expectations
implicit defs come from and where the Expectation objects can be build and
linked to Specifications.

Yet, I'm wondering about your precise use case and the way you want to
structure and reuse your specifications. For example it looks like this is
working:

import org.specs._

object test extends Application {

trait Functions extends Specification {
def bar(name: String) = name.length < 4 mustBe true
}

class Foo extends Specification with Functions {
bar("Foo")
bar("FooFoo")
}
println(new Foo().failures)
// List(org.specs.specification.FailureException: 'false' is not the same
as 'true')
}

There may be however side-effects I'm not aware on a "real" specification.

Eric.

Thinking about it again, that would be a cleaner solution:

import org.specs._
import org.specs.specification._
import org.specs.matcher._

object test extends Application {

trait Expectations extends ExpectableFactory with Matchers

trait Functions extends Expectations {
def bar(name: String) = name.length < 4 mustBe true
}

class Foo extends Specification with Functions {
bar("Foo")
bar("FooFoo")
}
println(new Foo().failures)
}

I can introduce the "Expectations" trait in the next release if it really
helps you.

Eric.