Framework's goal is to make testing a more pleasant experience than it currently is.
One of the goals of the framework is to achieve great readability. The syntax encourages to describe test cases using full sentences rather just a few words.
The Lambda Behave Specification design has several goals:
- To read like plain English.
- To encourage describing tests using long and descriptive sentences, rather than a few words.
- An API that is fluent and discoverable nearly entirely through IDE auto-completion.
There are many, many, expectations builtin to the framework - not just
Every specification suite starts its declaration using the
Suite.describe method. From that point onwards your IDE should be able to auto-complete the domain specific language for declaring specifications, but just in case you want more information, here's the details.
- If you want to specify a property about your system use
- If you want describe an expectation of that property, use
expect.that. This will get you to a fluent API restricted to the type of value that you're making the expectation about. The expectation system is based upon hamcrest. Lambda Behave doesn't compromise the ability to compose matchers in favour of fluency - if you want to compose in more complex flavours simply use
expect.that(value).is()and then you can use regular Hamcrest matchers. In my experience this is a rare, albeit useful, breakout option.
- If you want to setup or teardown data before or after each specification use
- If you want to setup or teardown data before or after each suite use
- Don't worry - I know some Java 8 lambdafied APIs don't deal with exceptions very well but you can throw exceptions in all our callbacks and the appropriate error will be reported, not just break the library.
More info available at GitHub.