BDD working together with Hexagonal architecture

title: BDD working together with Hexagonal architecture published: true description: Post about the benefit of using hexagonal architecture to ease real BDD tags: hexagonal,bdd,testing

Behaviour driven development is a development methodology that aims to create a good communication between the development team and the business. It also focus the testing on the actual behaviour of the system rather than focusing too much on low level details.

Sadly over the years cucumber (and behat) was used as an user acceptance testing tool or solely to write end to end tools. The creator of cucumber actually made a blog post titled "The training wheels came off" trying to explain why using cucumber as a web test automation was just a bad idea. He made a point that by doing so you would not reap any of the benefits that BDD should provide you.

Now let's hope you are not writing anymore scenarios like this one:

gherkin Scenario: Successful login Given a user "Aslak" with password "xyz" And I am on the login page And I fill in "User name" with "Aslak" And I fill in "Password" with "xyz" When I press "Log in" Then I should see "Welcome, Aslak"

Moving on to hexagonal architecture, A.K.A. ports and adapters. This architecture was coined by a gentleman named Alistair Cockburn in June 2005. It aims to write highly testable applications. It does so by providing clean layers and pushing all the technical bits to "adapters". The application core has to provide contracts (interfaces) "ports" that the infrastructure layers should implement (adapters).

In case you want to read more into the subject, I highly recommend Chris Fidao (fideloper) post.

Now what these two things can do for us.

Basically usually if use BDD tool but you are testing using the UI of your application (web testing, end to end), it means there is a big chance that these tests are slow and flaky. On the other hand, if you follow the hexagonal architecture motto:

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

It means that your should be able to write tests that bypass your web interface and go talk directly to the application layer. This bring two major benefits.

1. you can't write scenarios that are too focused on the UI (there is no more UI involved)
2. it will be super fast!!!

Just to prove my point here the output from a real application:

93 scenarios (93 passed) 384 steps (384 passed) 0m5.31s (58.20Mb)

Enjoy clean testable applications with up-to-date documentation written in Gherkin.

Bonus: these scenarios could be maintained by business analysis or domain expert.