In this second part of this series, we look at creating a first scenario and step definitions.
As a natural extension of Test Driven Development (TDD), BDD takes things a stage further.
TDD focuses on the use of Unit Tests to drive out a specification for your code and to guide your development. The nature of unit tests means that they are mainly practical for use by developers and, as the name suggests, only for unit testing.
Among other things BDD answers the following questions:
- How can we bring non-developers into the specification process?
- How can we bring the benefits of a TDD/BDD model to functional testing?
In BDD we describe testing scenarios in the Gherkin language, which looks a lot more like normal english than unit test code. Those test scenarios are then used to automatically build ‘step definitions’, which is the scaffolding code for our testing. We can then use unit test code within that framework to guide our development.
(credit: Tao of BDD)
Part 2 coming soon.
This video is a guide for developers to help them understand what changes need to be made to code to make it testable and sustainable. It uses parts of the SOLID principles to refine an example class.
- Single Responsibility Principle (SRP)
- Open/Closed principle
- Dependency Injection
- Unit Testing
A short tutorial showing how to use MongoDB to create a geospatial index.
26 Brains is a response to seeing a significant level of failure on technology projects. Whether it is the UK’s NHS IT programme or a small business website, there are too many examples where something that should have made a positive difference ended up doing the opposite.
The reasons are varied and, in my experience, seldom involve the quality of an individual’s code. Most of the failings I have observed can be linked back to poor communications and/or a mismatch of expectations.
Sometimes a client might have unrealistic expectations and a supplier might be unwilling to rock the boat and deal with that situation – this rarely ends well for either party. Sometimes a client wants X, but the supplier wants to sell Y – a sure fire way to end a project with disappointment. Sometimes project go in unexpected directions – sometimes good, sometimes bad – but either way, you need to take stakeholders on that journey. I am yet to find a situation where clarity and honesty have not gain the support of clients and stakeholders.
Even in times of failure, honesty, and a coherent plan of action will beat covering something up.
With 26 Brains, I want to promote best practice software development and IT implementation. I want to show that expectations can be met and even exceeded with the right planning and communication and when the vision is shared across all parties – whether the interest is financial, technical, administrative, user-based or design-based.