BDD – Use a DSL or natural language?


I have been reviewing Cucumber again – looking to integrate or do something similar for uSDLC. It has given me pause to consider the natural language approach as compared to the DSL approach.

Let’s start with an example for a web driven instrumentation. Natural language first.


Given that John has an administrator account
When John logs in
Then John can edit the configuration page

Now let’s look at the same logic using the Coffeescript DSL I have created for uSDLC.

Given
  assert administrators contains John 
 When
  browse '/login'
  enter
    Name: 'John'
    Password: 'secret'
  click 'Log In' 
 Then
  click 'Configuration' check title: 'Site Configuration' 

Or given that Coffeescript backs the DSL, I could wrap details up in functions and have s result like:


Given John has administrator rights
When we authorize John
Then we can go to the configuration page

So, what is the difference? More than immediately meets the eye. Let’s investigate by discussing benefits and disadvantages of both approaches.

Natural Language Benefits

  1. concise: most natural languages use fewer words than the explicit definitions required by a DSL.
  2. open: there are very few limitations in the words or sentence structure. As long as the parser can understand a sentence using regular expressions to extract variable data, then all is good.

DSL Benefits

  1. powerful: an internal DSL has all the power of its parent language when it is needed.
  2. flexible: domain specialists can look at existing statements and work out how to do something similar but different. Also parts of a statement can be used in more than one place.
  3. detail agnostic: provide behavior level descriptions only or provide more detail if your domain specialists want it.

Natural Language Disadvantages

  1. inflexible: only the exact statements defined at the developer level can be used.
  2. limited: to high level behavior descriptions.

DSL Disadvantages

  1. word limitations: internal DSLs must respect the structure of the parent language. I use Coffeescript because it gives me the best compromise available. It still takes effort to not use words like is, if and while out of context. This leads to more stilted sentences when trying for a natural language solution.

I am sure my preference shows – although I was still considering the options when I started this article. Domain specialists and business analysts will have no trouble reading DSL implementations like the first one above. They will appreciate the level of detail they need to be happy the system will work as needed. It is only when we have lots of technical scaffolding, dependency injection, object inheritance and all the other techniques in the software development world that we lose them.

uSDLC currently supports the DSL approach, but I will implement a pattern matching natural language actor in the near future as I see a case for choosing the best for a situation.

I am currently refactoring the uSDLC site to separate ready for use and incomplete features. Once done I will public the examples from this article so that you can see the implementations.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s