[ANN] Behavior.jl - Behavior Driven Development

Package Announcements
, ,
1

Hello!

This is an announcement of Behavior.jl, a tool for Behavior Driven Development (BDD) in Julia.
It is similar to tools like Pythons Behave, or the canonical BDD tool Cucumber.

This package was previously known as ExecutableSpecifications.jl before Julia 1.0, but is now re-introduced as Behavior.jl.

This package allows you to write specifications in the Gherkin format, like this

Feature: Making coffee

    Scenario: Making a cup of coffee
        Given that there is a cup in the coffee machine
         When the "Coffee" button is pressed
         Then the cup is filled with coffee

and executing this specification as code using Julia

using Behavior
using CoffeeMachine

hascoffee(cup::Cup) = cup[:coffee] > 0.0

@given("that there is a cup in the coffee machine") do context
    cup = Cup()
    machine = Machine()

    cupisinthemachine(machine, cup)

    context[:cup] = cup
    context[:machine] = machine
end

@when("the \"Coffee\" button is pressed") do context
    machine = context[:machine]
    coffeewaspressed(machine)
end

@then("the cup is filled with coffee") do context
    cup = context[:cup]
    @expect hascoffee(cup)
end

These tests can then be executed as part of the runtests.jl test file, like unit tests using the Test package.

The package is in a usable state, but is under continuous development, so things are likely to break between some versions.

Link to GitHub
https://github.com/erikedin/Behavior.jl

13 Likes
2

This sounds like an interesting package. And I heard such kind of software development paradigm for the first time. To me the keywords Given, When, Then seem to form a dialect like LINQ. Is there any specific domain that best to apply such a method?

(My initial impression is that it will help PMs to understand the code logic :laughing: )

1 Like
3

The Given/When/Then form is much simpler than LINQ. It’s just straight up matching the description of each step with a description in the code part.

I wouldn’t say there’s necessarily a domain that’s better or worse for BDD, but rather I’d say it’s appropriate when you want to communicate the software behavior to people that aren’t developers. You would not expect PMs to be able to read and understand unit tests, and you certainly wouldn’t expect customers to read unit tests either. With BDD you can communicate behavior, while using something similar to a unit test to actually verify this behavior.

That said, say that you’re writing a very technical simulation of some process. Then maybe you wouldn’t
care so much about communicating what the software does to non-technical people. You’ll expect that only people with roughly the same level of domain expertise will understand it, and that’s fine. Then you probably wouldn’t care about using BDD.

2 Likes