Behavior Driven Development Pycharm Python Django

Apr 12, 2016 15:59 · 1101 words · 6 minute read Python BDD Django PyCharm Guide

This article is a continuation of my first post about TDD in PyCharm with Python and Django. Here I will outline how behaviour driven development in PyCharm can be used in a scrum environment. However, scrum itself is another topic, but I will use these processes as a canvas.


I am neither an affiliate of JetBrains nor any of their products. In fact, I am a little disappointed with the most recent release of YouTrack and the number of critical bugs that they have, even now, after months of work. I am not saying that PyCharm or YouTrack or any other JetBrains products is flawless (clearly not) but these are the tools I found, which worked the best for my team and me.

Defining requirements

Before getting to the specs I need to commit requirements.txt file @2d6c959 Let’s start by defining our goals. The previous article defined requirements quite briefly so let’s elaborate on it a little more; There is another blog post that speaks about the way to describe the requirements which I will be using. For the time being, I will use . For the time being, I will use the Gherkin Syntax to create a few features.

In the previous post we’ve built an API so it’s time to do a catalogue now.

Feature: products catalogue
  To provide access to products
  As Any User
  I want to browse products catalogue

  Scenario: products on homepage
    Given there are set of Products in Database
      | id | title     | description   | price |
      | 1  | Product 1 | description 2 | 10    |
      | 2  | Product 2 | description 3 | 20    |
    When I go to /
    Then the page includes "Product 1"
    And the page includes "Product 2"

  Scenario: product detail page
    Given there is a Product in database
      | id | title     | description   | price |
      | 1  | Product 1 | description 2 | 10    |
    When I go to /products/1/
    Then the page includes "Product 1"
    And the page includes "description 2"
    And the page includes "10$"

This is a valid behave feature file which defines a catalogue feature and two scenarios of how can I use this feature. By the way, adding a file in PyCharm is Option ⌥ + Command ⌘ + A. Commit is Command ⌘ + K. Find commit here @850c187.

Good start, the suit can be ran with Control ⌃ + Option ⌥ + R in the PyCharm.

Running behave test with PycHarm

Of course, tests are failing which is good.

Tests are failing

The error message is

Traceback (most recent call last):
behave.configuration.ConfigError: No steps directory in 

Which means there is nothing to execute yet.

Making behave tests work

Ok, now let’s generate implementation steps for the Feature. First, let’s create features/steps folder with

by navigating to highlighted expressions in feature file and press **Option ⌥** + **Enter**. PyCharm suggest you 
create a step for particular expression.

![Create step defenition](/blog/images/bdd-with-python/Create step definition in PyCharm.png)

For some reasons *Create all steps definition* does not work as expected. It creates some definitions for certain 
phrases but not all of them. Must be a bug or something. So I used *Create step definition* option. Now, we 
have blank steps defined for every step. Let's run them 

![Run empty steps](/blog/images/bdd-with-python/Behave implementation steps defined.png)

They are passing now. Which is expected but not very good. I don't know why PyCharm team decided to put ```pass``` as
 default implementation like this:

@step('the page includes "Product 2"')
def step_impl(context):
    :type context: behave.runner.Context
This approach creates whole bunch of problems. Particularly, I don't like it because tests are passing now which makes it easy to forgot some of the implementation steps. I would say assert False would be much better as a default:
@step('the page includes "Product 2"')
def step_impl(context):
    :type context: behave.runner.Context
    assert False
I have modified steps that suppose to assert something to assert False. Now tests are failing. [@b2c4ee24]( ![Behave tests are failing again](/blog/images/bdd-with-python/Behave tests are failing again.png) ## Django context configuration It is time to configure behave. Let's run behave tests inside the Django context. To do so we have to add and several lines in it (@043ac7b)[]:
import os
import django

os.environ['DJANGO_SETTINGS_MODULE'] = 'test_project.settings'

def before_all(context):
Another good thing would be to create setup and teardown methods just like typical test cases. In these methods, we will be creating test database each time we run tests and delete it when tests finished. There are many other things that could be done but let's keep it simple for now. In this example, we will use DiscoverRunner, but I think it might not work for older versions of Django:
from django.test.runner import DiscoverRunner

def before_all(context):
    context.test_runner = DiscoverRunner()
    context.old_db_config = context.test_runner.setup_databases()

def after_all(context):
We have database managed now [@6c471b3]( And one more thing that could be added is an ability to run scenarios in transactions and roll them back after each scenario. That's fairly simple too:
from django.test.testcases import TestCase

def before_scenario(context, scenario):
    context.test = TestCase()

def after_scenario(context, scenario):
    del context.test
I think we are pretty much done with a configuration so let's get into implementation of the steps. ## Behave scenarios implementation One nice thing about PyCharm is that it highlights patterns. I've modified my test for common case and PyCharm automatically recognised which parts of the statement are variables. Now I can re-use that ```@given``` statements for any model to create my test data. [@6058808c]( ![Highlighting of the variables in PyCharm](/blog/images/bdd-with-python/Highlighting of the variables in PyCharm.png) The next step will be implementing the navigation. One thing that is missing is the server we can send requests to. But since we have everything in place it is only a matter of changing a test case class in `````` to ```LiveServerTestCase```. Sending requests to that server will be using ```urllib```. [@2281145](
@when("I go to /")
def step_impl(context):
    :type context: behave.runner.Context
    context.response = urllib.request.urlopen(
Let's run it! ![Navigation implemented](/blog/images/bdd-with-python/Navigation implemented.png) We've got an exception:

HTTPError: HTTP Error 404: Not Found ```

This is a good sign. This means we actually have a test server running and are able to request it. The last step is to assert the response. Let’s go through the same with the second scenario. I’ve re-factored a little bit and I’ve also added implementation for the second scenario @2281145

Generally speaking it is possible to write behave tests in such a way that allows you to reuse your code often. But that’s another entirely another subject.

Actual feature implementation

The actual implementation took maybe half an hour in total. Since it is just a demo, my intent was to show BDD practices rather than coding of the features. Finally I have tests passing at my last commit @9cbdbf31 I have added actual API endpoints and corresponded implementation.

Behave tests passed

It worked!