Behaviour Driven Development: how to organise the BDD Components


There are several approaches, depending on the environment you are working into.

If you are working in an agile environment, your code session could be driven by the user story you are implementing. In this case, each BDD Component could contain all the BDD Methods that you are going to use during the development of the acceptance tests for a single user story. This approach allows you to keep your classes less “crowded” from a huge pool of methods. It perhaps could mean you have to duplicate some BDD Methods throw the BDD Components because much code could be in common with each user story, especially for the “Given” methods. In this cases, if you are developing using Dynamic Components, you could use a second BDD Component: a generic one that is not specifically related to any user story. In this component, you can put all the BDD Methods that you are going to use frequently, across the user stories you are going to implement. After that, you have to add as a component the generic BDD Component plus the BDD Component you are developing for your user story. The BDD Framework can recognise both the components, allowing you to configure your test using the BDD Methods from both classes.

If you are not coding using the help of the user stories, but just coding some generic or specific requirement without clear acceptance criteria (development typical of waterfall processes), you may have not a guide for separating your BDD Components properly. In these cases, you are going to have huge BDD Components, full of methods, without any suggestion how to split them into smaller classes. There is something you can do for containing the problem. For example, you could identify some areas in your software and split you BDD Components following that type of aggregation. An example could be the options panel with multiple pages: In this case, each page could identify a different BDD Component.


Back to: Behaviour Driven Development: how to organise the scenes Read next: Behaviour Driven Development: Experimenting