Monday, November 22, 2021

Glimmer DSL for Specification - Specification-First Engineering

Despite Ruby's highly expressive nature, most testing toolkits written in Ruby are either imperative (e.g. using `assert` or `expect`), thus losing expressiveness and focusing software engineers on the wrong thing, or mix non-Ruby code with Ruby (e.g. cucumber & gherkin), thus missing out on the simplicity of Ruby.

Glimmer DSL for Specification aims to provide a simple minimalistic and noun-based declarative syntax. No more verbs! It is time to think declaratively not imperatively!

As such, software engineers focus on Requirements Specification at the Use Case level whereby each use case is composed of multiple scenarios. No need to specify scenario steps. The code is the steps!!!

Also, no need for extra DSL constructs for making comparisons in verification statements. Just use plain old Ruby and let the library figure out the rest!

For example:

That tells me the whole story without needing either `assert` or `expect`. It just contains plain Ruby code for performing the comparison.

Another example:

That states a few extra facts in addition to the last statement in the scenario denoting the final verification. Software engineers will not have to write awkward verification code they hate anymore (e.g. assert or expect) as even software verification code is written with basic Ruby.

Upon failure of a fact with a String equality/inequality comparison, the library will automatically print the values of the two compared String objects.

Glimmer DSL for Specification emphasizes the idea of Specification-First Engineering. The library was written specification-first utilizing itself. In fact, here is the initial specification of glimmer-dsl-specification to prove it!

Note that the library is very new and experimental, so it might change course significantly. Also, despite the bold ambitious statements, there might be obvious blind spots that your feedback would help shine light upon to improve the library. As such, ideas and suggestions are greatly welcome.

No comments: