Coding Dojo 1 Done Done

In last friday was first coding dojo where topics were Cucumber (and Gherkin) and ATDD (Acceptance Test Driven Development). Class was split to two groups where expert teams were introduced their topic. Expert team where I belong to introduced ATDD (see slides in Finnish).

ATDD

ATDD is team practice which concentrate to external quality and it contains TDD (Test Driven Development). Specification workshop consist of project key members e.g. developers, testers, product owner, architect and technical writers. These members can vary during software project. During specification workshop user stories are selected and specifications are written down. These specifications will be implemented to executable specifications. Next phase is feature implementation so tests can be executed successfully. Implementation will follow TDD-cycle. Last phase is demonstration and customer approval. There are many ATDD benefits but few to mention this practice will improve communication between team members and enable fast feedback. The customer is responsible for certification and approval of functionalities which facilitates team work. There are also many problems to use this practice. Customer teaching to test driven development could be tricky and customer doesn't have any resources or knowledge. Writing automatically executable tests could be hard e.g. embedded systems. There are many tools in different software environments e.g. FIT, Robot and Cucumber.

Cucumber and Gherkin

Other expert team highlights Cucumber and Gherkin. Cucumber is ruby based BDD tool which executes plain-text functional descriptions as automated tests. Cucumber can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber understand Gherkin language. It is a Business Readable, Domain Specific Language that lets you describe software’s behavior without detailing how that behavior is implemented. These functional descriptions are written in .feature files. Each feature to own file. Communication is better if people can use their spoken language. Cucumber supports currently over 40 spoken languages and steadily growing.

Example of functional description from wiki pages:

Feature: Serve coffee
  In order to earn money
  Customers should be able to
  buy coffee at all times

  Scenario: Buy last coffee
   Given there are 1 coffees left in the machine
   And I have deposited 1$
   When I press the coffee button
   Then I should be served a coffee

NOTE: Keywords used to describe feature and scenario are bold ('But' is also supported keyword but not used in this example). These keywords should be written case sensitive and ':' should be added after Feature and Scenario.

From theory to practice

One of our course instructors act as business owner. He need few user account management features for Bowling company's web site e.g. create new user account, list all users and filter results. Our group ask questions to clarify requirements. We practice Gherkin description by pair coding with text editor. This pair is only allowed to speak freely. Other members can ask open questions to present own ideas but no more. One pair member was changed after 5 minutes and this way every group member can participate to pair coding.

We didn't implement step definitions because time of coding dojo was limited. Steps after writing feature scenarios aren't now familiar but I think this was very good way rather than implementing functionality. It seems to be quite simple to continue by my self after looking documentation from Cucumber's web page. Cucumber (and Gherkin) has been documented quite well and Internet offers a lot information.

We didn't get solved last feature due time was over. But here is my answer how it could be resolved. I am not sure can table include table and haven't test it yet. If you have better solution please be free and comment.

Feature: List users
  In order to modify user informations 
  Owner should be able to list users
  with free query filter
  Scenario: List users
    Given system have users <users>
    | username | fname | lname | picture |
    | foo      | bar   | baz   | nil     |
    | n00b     | l33t  | fff   | n00b.jpg|
    When I set search filter as <filter>
    | filter |
    | nil    |
    | foo    |
    Then I should see <result>
    | filter | users                                |
    | nil    || username | fname | lname | picture ||
    |        || foo      | bar   | baz   | nil     ||
    |        || n00b     | l33t  | fff   | n00b.jpg||
    | foo    || foo      | bar   | baz   | nil     ||

Conclusion

ATDD is powerful team practice and can managed with tools e.g. Cucumber and Gherkin. This combination can guarantee all features are done like customer wants to. There could be problems to take in use this team practice in software projects because it could make customer, managers, developers and other team members to think that this is yet another complicated practice. Actually it should enable all communicate same language during whole project and remove uncomfortably feelings has every requirement done done.