So this is an interesting question - if you needed me to answer this without prep time, I’d say it is designed to work atop a BDD framework, not that it’s “doing BDD.” Let me explain my logic and then we can really dissect it.
As I understand it, BDD (Business Driven Design) is less a thing you do and more a process of thinking by moving the planning left and including the business partners in on the test development process. Cycle doesn’t do this for you. Rather, it’s designed to be used for this development style. The best way I can illustrate this is by describing how we use it here in Cycle Labs -
- Before even opening Cycle, we have a conversation with our partners
- What are their goals?
- What are they trying to test?
- What are they really trying to test?
- We explain we aren’t the experts of their system and they we succeed together or we don’t succeed - this makes a clear that we’re going to rely on their business knowledge
- After this initial conversation, we move on to a series of “BDD Sessions.”
- This puts the partner in the position of authority, hopefully making them feel more empowered
- It lets us take a guided tour through their process to ask questions and better understand the various fail states
- Once we’ve captured information from the BDD sessions, we draft up Test Specs to basically show that we know that processes and pass them to the partner for approval
Finally we open Cycle and begin development
So, why did I write all this and then barely describe the Cycle portion of this? As I said at the top, BDD isn’t something you do. It’s a mode of thinking. It’s a design process. Everything I have described is just as important if not more important than Cycle’s abilities, as it ensures our partners are involved with development and have a stake in its success.
But didn’t I also say Cycle was designed to work with BDD? Good catch. So what do I mean by that?
Cycle is a Gherkin language. We write in plain text and can describe our process as part of the development. When using more traditional coding languages, developers have to write in comments to describe what’s happening. In Cycle, that’s just part of the code itself.
So when we take notes in our BDD session, we’re already laying out the framework for the test. When we draft up the Test Specs, we’re fleshing out that framework and noting areas we can create utilities for better reuse and DRYer code. When we have that initial sit-down meeting and determine what the client’s needs are, we are already designing, through conversation, what test style we’re going to utilize.
So, does Cycle “Do BDD?” I don’t think so. I propose it is designed to excel within a BDD framework.