behavior Driven Development is an excellent process to follow in software development. With testing often a practice that is pushed aside to the last minute (or ignored, entirely), baking the process into your daily workflow can prove to be hugely beneficial to the quality of your code. The structure and design of the tests, coupled with the Gherkin syntax makes tests easy to read – even for team members with non-technical backgrounds.
All code should be tested thoroughly, meaning that defects should ideally never reach production. If they do, then a thorough test suite, focused on the behavior of your application as a whole, ensure that they are easy to both detect and fix. This speed, clarity, focus and quality in your code is why you need to be adopting this process…now.
What is Behavior Driven Development?
Behavior Driven Development (which we will now refer to as “BDD”) follows on from the ideas and principles introduced in Test Driven Development. The key points of writing tests before code really apply to BDD as well. The idea is to not only test your code at the granular level with unit tests, but also test your application end to end, using acceptance tests. We will introduce this style of testing with the use of the Freshen testing framework.
Behavior Driven Development (BDD) is a subset of Test Driven Development (TDD).
The process can be simply defined as:
- Write a failing acceptance test
- Write a failing unit test
- Make the unit test pass
- Refactor
- Make the acceptance test pass
Rinse and repeat for every feature, as is necessary.
BDD in Agile Development
BDD really comes into its own, when used with agile development.
Tip: Refer to The Principles of Agile Development for more information on agile development methods.
With new features and requirements coming in every 1, 2 or 4 weeks, depending on your team, you need to be able to test and write code for these demands quickly. Acceptance and unit testing in Python allows you to meet these goals.
Acceptance tests famously make use of an English (or possibly alternative) language format “feature” file, describing what the test is covering and the individual tests themselves. This can engage everyone in your team – not just the developers, but also management and business analysts who otherwise would play no part in the testing process. This can help to breed confidence across the whole team in what they are striving to achieve.
Gherkin Syntax
Acceptance tests usually make use of the Gherkin Syntax, introduced by the Cucumber Framework, written for Ruby. The syntax is quite easy to understand, and, in the Freshen Python package, makes use of the following eight keywords to define your features and tests:
- Given
- When
- Then
- And
- Feature:
- Background:
- Scenario:
- Scenario Outline:
Below, you can review these keywords in action, and how they can be used to structure your acceptance tests.
Feature Files
Feature files are written in plain English, and specify the area of the application that the tests cover. They also provide some setup tasks for the tests. This means that you are not only writing your tests, but are actually forcing yourself to write good documentation for all aspects of your application. So, you can clearly define what each piece of code is doing and what it is handling.
An example feature file would take the form of (my examples are written using the ‘freshen’ python package. More details can be found below.):
From this simple example, you can see how straightforward it is to describe your tests and share them across the various people involved in your team.
There are four key areas of note in the feature file:
- Importing the step definitions – Informs Freshen where to look for your steps (see the Steps section below.) These are the mappings to each line to execute Python code underneath.
- Feature block – Here is where you write documentation for what this group of tests is going to cover. No code is executed here, but allows the reader to understand exactly what this Feature is testing.
- Background block – Executed prior to every Scenario within the Feature file. This is similar to the
SetUp()method and allows you to perform necessary setup code, such as making sure you are on some page, or have certain conditions in place. - Scenario block – Here, you define the test. The first line serves as the documentation again, and then you drop into your Scenario to execute the test. It should be fairly easy to see how you can write any test in this style.
Steps File
Following on from the Feature file, we have the steps file underneath. This is where the ‘magic’ happens. Obviously, the Feature file, itself, will not do anything; it requires the steps to actually map each line to execute Python code underneath. This is achieved through the use of regular expressions.
“Regular Expressions? Too complex to bother with in testing” can often be a response to RegEx’s in these tests. However, in the BDD world, they are used to capture the whole string or use very simple RegEx’s to pick out variables from a line. Therefore you shouldn’t be put off by their use here.
Regular Expressions? Too complex to bother with in testing? Not in Freshen. Simple and Easy!
If we review an example. you’ll see how easy the Steps file follows on from the Feature.
The first thing worth noting is the standard imports at the top of the file. So, we need access to our ‘calculator’ program and, of course, the tools provided by Freshen. Then, we can begin to define the steps for each line in the Feature file. We can see that, as explained earlier, the regular expressions are mostly just picking up the whole string, except where we want access to the variable within the line.
If we use the “Given I have pressed ‘xxx’” line as our example, you can see that the line is first picked up using the @Given decorator. Then, you use the 'r' character at the start to indicate the regular expression. Following that, it’s just the line itself and a very simple RegEx to match anything within the quotes – the button in this case. You should then see that the Python method follows directly after this, with the variable passed into the method with whatever name you wish. Here, I have called it, “button”.
Another item of note here is the use of “scc”. This is the Scenario Context Container, and allows variables to be used across steps within a scenario. If we didn’t, all variables would be local to their method, but, here, we create an instance of Calculator() once, and then access that in each step.
Freshen Python Package
As you can hopefully see, the Freshen package is quite simple to pick up and begin using. The installation is straight forward, following the usual pip install pattern that most Python developers will be familiar with.
Perform the following steps to begin using Freshen:
$ pip install freshen-
$ nosetests --with-freshen /path/to/example.feature– to run your tests. You can either run just one feature file, or, if you pass a directory of feature files, you can run all of them.
Alternative Tools
There are plenty of alternative options within Python to do this form of testing. We have examples, such as Behave, Lettuce and also Cucumber, which, as mentioned, defined this structure. The other tools are essentially clones/ports of Cucumber. Cucumber can be used with Python code, via the use of a Ruby-Python interpreter, but that is beyond the scope of this tutorial.
- Behave – a near exact port of Cucumber into Python. Has a good level of documentation, and is updated constantly by the developers. They also offer a comparison with other tools here, which is worth a read.
- Lettuce – another direct port of Cucumber, featuring tutorials and examples on their website, and simple installation tools, such as ‘pip’.
The key point, with all of these tools, is that they are all more or less the same. Once you have mastered one, you’ll quickly pick up on the others, should you choose to switch. A quick review of the documentation should be enough for most developers, who are proficient in Python.
Advantages
You can dive into refactoring confidently.
There are significant advantages to be made using a thorough test suite. One of the major ones revolves around the refactoring of code. With a robust test suite in place, you can dive into refactoring confidently, knowing that you have not broken any previous behavior in your application.
Final Thoughts
Having worked in a team using the process and tools outlined above, I have personally experienced the huge advantages of working in this manner. BDD provides your team with clarity, focus, and the confidence to deliver great code, while keeping any potential bug to a minimum.
Entradas
No hay comentarios:
Publicar un comentario