CODEWITHSUNDEEP
scalabddscalatestspecs2
tiagoboldt
tiagoboldt

Reputation: 2426

BDD in Scala - Does it have to be ugly?

I've used lettuce for python in the past. It is a simple BDD framework where specs are written in an external plain text file. Implementation uses regex to identify each step, proving reusable code for each sentence in the specification.

Using scala, either with specs2 or scalatest I'm being forced to write the the specification alongside the implementation, making it impossible to reuse the implementation in another test (sure, we could implement it in a function somewhere) and making it impossible to separate the test implementation from the specification itself (something that I used to do, providing acceptance tests to clients for validation).

Concluding, I raise my question: Considering the importance of validating tests by clients, is there a way in BDD frameworks for scala to load the tests from an external file, raising an exception if a sentence in the test is not implemented yet and executing the test normally if all sentences have been implemented?

Upvotes: 14

Views: 6275

Answers (4)

SemanticBeeng
SemanticBeeng

Reputation: 977

Eric's main design criteria was sustainability of executable specification development (through refactoring) and not initial convenience due to "beauty" of simple text.

see http://etorreborre.github.io/specs2/

The features of specs2 are:

  1. Concurrent execution of examples by default
  2. ScalaCheck properties
  3. Mocks with Mockito
  4. Data tables
  5. AutoExamples, where the source code is extracted to describe the example
  6. A rich library of matchers
  7. Easy to create and compose
  8. Usable with must and should
  9. Returning "functional" results or throwing exceptions
  10. Reusable outside of specs2 (in JUnit tests for example)
  11. Forms for writing Fitnesse-like specifications (with Markdown markup)
  12. Html reporting to create documentation for acceptance tests, to create a User Guide
  13. Snippets for documenting APIs with always up-to-date code
  14. Integration with sbt and JUnit tools (maven, IDEs,...)

Specs2 is quite impressive in both design and implementation. If you look closely you will see the DSL can be extended while you keep the typesafe-ty and strong command of domain code under development.

He who leaves aside the "is more ugly" argument and tries this seriously will find power. Checkout the structured forms and snippets

Upvotes: 0

Eric
Eric

Reputation: 15557

This is all about trade-offs. The cucumber-style of specifications is great because it is pure text, that easily editable and readable by non-coders.

However they are also pretty rigid as specifications because they impose a strict format based on features and Given-When-Then. In specs2 for example we can write any text we want and annotate only the lines which are meant to be actions on the system or verification. The drawback is that the text becomes annotated and that pending must be explicitly specified to indicate what hasn't been implemented yet. Also the annotation is just a reference to some code, living somewhere, and you can of course use the usual programming techniques to get reusability.

BTW, the link above is an interesting example of trade-off: in this file, the first spec is "uglier" but there are more compile-time checks that the When step uses the information from a Given step or that we don't have a sequence of Then -> When steps. The second specification is nicer but also more error-prone.

Then there is the issue of maintaining the regular expressions. If there is a strict separation between the people writing the features and the people implementing them, then it's very easy to break the implementation even if nothing substantial changes.

Finally, there is the question of version control. Who owns the document? How can we be sure that the code is in sync with the spec? Who refactors the specification when required?

There is no, by far, perfect solution. My own conclusion is that BDD artifacts should be in the hand of developers and verified by the other stakeholders, reading the code directly if it's readable or reading an html/pdf output. And if the BDD artifacts are owned by developers they might as well use their own tools to make their life easier with verification (using a compiler when possible) and maintenance (using automated refactorings).

Upvotes: 9

tiagoboldt
tiagoboldt

Reputation: 2426

I've just discovered a cucumber plugin for sbt. Tests would be implemented under test/scala and specifications would be kept in test/resources as plain txt files. I'm just not sure on how reliable the library is and if it will have support in the future.

Edit: The above is a wrapper for the following plugin wich solves perfectly the problem and supports Scala. https://github.com/cucumber/cucumber-jvm

Upvotes: 12

Jens Schauder
Jens Schauder

Reputation: 81940

You said yourself that it is easy to make the implementation reusable by the normal methods Scala provides for this kind of stuf (methods, functions, traits, classes, types ...), so there isn't really a problem there.

If you want to give a version without code to your customer, you can still give them the code files, and if they can't ignore a little syntax, you probably could write a custom reporter writing all the text out to a file, maybe even formatted with as html or something.

Another option would be to use JBehave or any other JVM based framework, they should work with Scala without a problem.

Upvotes: 6

Related Questions