Thoughts on test description idiom

[Howard Lewis Ship]

Here's a Spock idiom Ive been using increasingly; having a data value in my where: block that is only used as part of the method name.

class MessagesImageSpec extends Specification {

  @Shared

  Messages messages = MessagesImpl.forClass(TargetMessages)

  @Unroll

  def "contains key: #desc"() {

    expect:

    messages.contains(key) == expectation

    where:

    key       | expectation | desc

    "no-args" | true        | "base case"

    "xyzzyz"  | false       | "key not present"

    "No-Args" | true        | "case insensitive"

  }

  . . .

This seems like the best way to get meaningful test names without lots of small test methods (i.e., a separate method for each of the three cases).

Thoughts?

--
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

[Peter Niederwieser]

It's an idiom I also use from time to time. At one point I thought about supporting something like this:

where:

key       | expectation

"base case"

"no-args" | true

"key not present"

"xyzzyz"  | false

"case insensitive"

"No-Args" | true

But I wasn't fully convinced. If the body of the test is short (like here), I nowadays tend to go for the straightforward:

def "base case"() {

  expect:

  messages.contains("no-args")

}

def "key not present"() {

  expect:

  ...

 }

I'm still considering to support somethink like this, which can be handy at times (and is a frequent idiom in JUnit):

@Fragment // not a standalone/complete feature method but can use full syntax

def containsKey(key, expectation) {

  expect: 

  messages.contains(key) == expectation

}

def "base case"() {

  containsKey("no-args", true)

}

def "key not present"() { ... }

If all you need is assertions, you can of course just go:

void containsKey(key, expectation) {

  assert messages.contains(key) == expectation

}

def "base case"() {

  expect:

  containsKey("no-args", true)

}

Is there anything here that you like?

Cheers,

Peter

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To post to this group, send email to spockfr...@googlegroups.com.
To unsubscribe from this group, send email to spockframewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spockframework?hl=en.

[Howard Lewis Ship]

I really like the tabular format of my approach; I think it's also more concise as well. It does fuzz the difference between a method and a feature test, as a single method is potentially testing multiple features.

[James Carr]

Thanks for posting this guys... I was just trying to figure out something like this yesterday and did not know about the @Unroll annotation.

Thanks,

James