I'm trying to see how this is more than just "Asserts by any other name."
I'm all for clear syntax, but:
Specify.That( someObj.SomeMethod() ).ShouldBeFalse();
vs:
Assert.IsFalse( someObj.SomeMethod() );
feels like verbosity for the sake of verbosity.
It doesn't feel like I'm defining a "specification" especially since I'm actually calling "someObj.SomeMethod". I'm not defining rules or constraints, or doing anything clever with relfection, I'm just asserting with more characters.
I agree with Vandenberg, much too low level.
I agree. Specifications are generally considered to be at higher level than unit testing. I would also argue that since clients don't write unit tests, the won't be writing code behaviors either. It's too low level.
Oh I get it.....it's unit tests written in VB ;-)
I'll throw my hat in the "me too" ring. I thought it was interesting at first, but really it's just a verbose way of doing asserts.
Is it more readable? Maybe to someone who doesn't code, but is that really worth it since the audience who codes should know how to read code and not a book.
Having said that, I think there's a place for BDD or SDD (specification driven development, but sounds like a venerial disease doesn't it?) and I can see some growth towards that, but not here.
Also, you can have a look to Specter, specter.sf.net, which is an other BDD framework, but uses the nice Boo language features. Worth a look.
This sounds a bit like how Eiffel works, however, as was said, this is example is just Asserts with a different class name.
COBOL, lol.
I think I get it: "English-like sin tax"
A quick look at the site shows that they seem to want a new name for TDD rather than a new game. ;)