easyb will support ignoring
The next release of easyb will support the notion of ignoring entire stories or various scenarios within in story via the ignore keyword.
As currently coded, ignore supports two features– either ignoring the entire story all together via ignore all or you can pass in one or more scenario names which to ignore. This selective ignoring feature can take three different types of parameters– a single String (which represents the particular scenario to avoid), a series of Strings (separated by commas, which represents a series of scenarios to ignore) or a Collection of Strings (which also represents a series of scenarios not to run).
As you can see, this keyword is very much like the standard xUnit paradigm’s ignore; however, it might be a bit more flexible as you can specify just what scenarios to ignore and which to presumably run in one statement, rather than having to repeatedly issue ignore statements.
For instance, the following story, dubbed noworking.story, would be completely ignored:
ignore all
scenario "this is purposely a broken scenario", {
given "some variable with a value", {
val = 12
}
then "to force an error, one should verify it is not 12", {
val.shouldNotEqual 12
}
}That is, nothing within the story would be executed; consequently, no state would be captured– nothing is pending either. As of right now, pending and ignoring stories/scenarios are completely different and also convey different meanings.
Using the same exact story, you could also specify the particular scenario to ignore by passing it its name as follows:
ignore "this is purposely a broken scenario"
scenario "this is purposely a broken scenario", {
given "some variable with a value", {
val = 12
}
then "to force an error, one should verify it is not 12", {
val.shouldNotEqual 12
}
}If this same story had more than one scenario, you could then either continue passing in comma delimited scenario names or just pass in a collection like so:
ignore "this is purposely a broken scenario",
"this is also a purposely broken scenario"
//or
ignore ["this is purposely a broken scenario",
"this is also a purposely broken scenario"]
//which is the same as saying
coll = ["this is purposely a broken scenario",
"this is also a purposely broken scenario"]
ignore collThis feature is currently considered a prototype and only lives in the tip of easyb’s SVN repository. Feel free to download the source and give it a spin for yourself (building easyb is easy, man!)!
| Related odds and ends | ||
|---|---|---|
Sunday 31 Aug 2008 | Developer Testing, Dynamic Languages, Groovy
[...] Original post by Andy [...]
This seems a bit error prone: make one typo in the ignore statement (which is likely, considering how long these names are) and you will get unexpected results. It also seems to violate DRY in some way.
Why not use booleans instead? Or groups with shorter names so that you can apply ignore to an entire set of scenarios? Or regexps? (ignore .*broken.*)
Cedric- yeah, you raise an excellent point! I like the idea of regexps. Groups is also interesting (also one of my most favorite TestNG features, baby!)– do you care to further elaborate?
Thanks again, friend!
Cedric– I’ve created an issue in the project’s management system for your regex idea! Thank you!
We forked test/spec (http://github.com/relevance/test-spec) a while back to enhance it with similar functionality, but we took a different approach that you might find interesting. To disable a spec, we simply put an “x” in front of it. In test/spec, “it” becomes “xit”. The easyb equivalent would change “specify” to “xspecify”. It’s incredibly handy to be able to make the change that easily, and I believe it addresses Cedric’s concerns as well. And when you run the tests, it reports the number of tests run, the number passed/failed, *and* the number of disabled tests that were skipped.
We also added the inverse of this functionality: the ability to run a single test (i.e., a “focused” test). In a file with a large number of tests, it’s incredibly useful to be able to tell test/spec to run just one test (i.e., the one you’re working on at the moment). And while you want to avoid having slow tests mixed in with your faster test suite, if you find yourself debugging the lone fast test in an otherwise slow set of tests, you can imagine the advantages of “focusing” on that single fast test without waiting for the others to run.
Food for thought.
Jason- indeed, all great ideas!! I have been thinking about the single behavior running too– I’ve found myself needing it on more than one occasion! Speaking of the xit– within in JUnit, I often just put an _ in front of a test case so as to force the framework to ignore it….
Thanks for your ideas– I’ll add an issue to capture these!