BDD

In the last few years, behaviour-driven development has entered my consciousness. Robert ‘Uncle Bob’ Martin was probably the first one. His videos introduced me to his FitNesse.

I tried to get it to work with a recent version of Java, but it fails in ways I don’t understand. I don’t have the motivation to track it down.

Then I came across Cucumber and Gherkin. The simplicity of getting it to work, the flexibility, and the fact it works so well with Source Control made it feel like a breath of fresh air.

Write tests in Gherkin, try them out, get them working, and repeat. That makes a nice short reward loop, motivating me to move forward in my program.

“When the rewards are too far away, the motivation to stay focused is low.”

Recently, I’ve been trying to figure out how to automate ticketing. Consider a GitHub issue: https://github.com/alesgaroth/juv/issues/1. I wrote up some Gherkin to describe what I wanted to happen.

If I wrote up enough Gherkin to describe what I wanted completely, I would know that the ticket could be closed when all of those tests passed.

If my build system could read the Gherkin out of the ticket and check that all those tests passed, it could close the ticket for me without me having to do it manually.

If my monitoring system could read the Gherkin and set up automated tests against production to monitor if it’s working correctly, I wouldn’t have to worry about it anymore.

For that matter, I could run a script to copy the Gherkin Scenarios from the ticket into a local .feature file, check it in, and mark it as “In Progress” when I wanted to start working on it.

My workflow as a developer would then be:

1. Choose a ticket
2. Run the script with the ticket number
3. Make each test pass
4. Create Pull Request
5. Code Review responses
6. Merge to main

I wouldn’t have to fiddle with the ticketing software, remembering to close it or move it to In Progress instead of:

1. Choose a ticket
2. Mark it as In Progress
3. Figure out what tests to write
4. Make each test pass
5. Create a Pull Request
6. Code Review responses
7. Merge to main
8. Verify it works when it hits production
9. Close the ticket

That’s the ideal process. Usually, it turns into something like this:

1. Choose a ticket
2. Write some code to see if I can figure out how to do it.
3. Open a Pull Request
4. Right, I need a ticket. Let’s open the ticket
5. Right, I need tests. Quick write some tests
6. Weird, I found a bug while writing the tests.
7. Make each test pass
8. Code Review responses
9. Merge to main
10. At standup, mention that I already had it merged days ago, and watch the presenter close it for me.

Having some of that automated away would make it less intimidating and naturally help me keep the order.