behave Project/folder Structure

Background:

In all the three tutorials i.e. Basic, Intermediate and Advanced, we have used behave project template and used it and wrote our scenarios. However we never got a chance to talk about the overall project structure and why a certain file/folder exists the way it is structured. Obviously there is some convention (meaning a rule is defined) and there is some configuration (flexibility to modify some rules through configuration). In this post we will first talk about the folder structure we adopted all through the tutorials and set a stage, so that we don’t have to worry one fine day.

behave Project structure:

Compared to other programming languages, python in my opinion has the best of both worlds of Ruby and Java, simple elegant structures like Ruby, yet enterprise ready like Java, though a very noteworthy observation not to miss before we go into frameworks discussion. Below is a high level illustration. I will explain below in addition to the call outs.

behave_folder_structure

  1. features folder is where we write all .feature files i.e. behave features and scenario – describe the behavior of application in .feature files
  2. features folder also contains steps folder – this is where all the glue code , otherwise automation code which we have been writing so far goes into .py files
  3. features folder also contains environment.py – we will explain in detail below
  4. At the project root, behave.ini contains all the configuration options that behave parser understands is present. It contains options like color, std_capture, reports format etc.
  5. requirements.text contains all the python libraries that are used in this project and manged by pip. We specify exact versions of python libraries , which is a best practice.
  6. LICENSE.txt contains license information for this project
  7. README.md contains all the read me information for this project and is formatted well on github
  8. results.json gets generated when we specify requirements for json reports
  9. The .log file is generated if we specify the configuration flag for logging true.

environment.py:

environment_py

When behave is run, there is a certain sequence of events that happen before the actual scenario is run. All python code in environment.py gets loaded into the python runtime context. Hence we would want to load up all hooks and library entry points and their modules in the environment.py file as below for example.

It is important to note here that we can externalize any python code and then include it in context, by using environment.py file. For example, I can have my python modules and classes files in a completely different folder, however if I intend to use them, then I have to import them into environmen.py. When we discuss frameworks in details,we will talk about re-usability and how we can keep python code in separate folder and include those modules/classes into the current project and some other behave project too.

before_all

If we want to execute code at the beginning, then we use this hook. I don’t intend to have anything here at this point.

before_feature

I use this hook to create my logger handle and set the handle in behave context.

before_scenario

I initialize my browser handle or selenium web driver handle based on the user choice of browser

 

after_scenario

I create a folder for failed screenshots if it doesn’t exist and dump all screenshots in this folder. Also I quit webdriver since I want to use a fresh webdriver session for every scenario

after_feature

I don’t do anything this point

after_all

If archiving is chosen by user, I archive the screenshots folder and zip it up. Of course if we want to archive anything else from this folder, we have to add the logic. For now just screenshots