Separate location for feature files and step implementation

[monicalicareti]

Hi @jenisys @ALL,

I am trying to obtain the following structure in my project:

sw_repository
|- tests
    |- unit_tests
    |- xil_tests
        |-features
        |-python_steps_implementation <--- this should be a git submodule
           |-steps
           |-environment.py
           |-other_dependencies

For some organization reason, the project wants the steps implementation, together with environment.py to be maintained in a different location and be brought in as a git submodule.
This makes the step implementation end up in a separate folder from the .feature files, which will be native to the SW repository.

I have tried:

• to use a behave.ini config file and specify paths=Tests/xil_tests/python_steps_implementation, but then it cannot find the feature files
• to launch behave Tests/xil_tests/features but it cannot find the steps directory and does not take into account the path in behave.ini

Is there a way to make behave work with such a layout?

Thank you!

[jenisys]

Sorry, the answer is NO.

• steps directory and environment.py file must be where your feature files are (as convention)
• BUT: You can import the contents of these files/directory from other places (as normal Python packages; your PYTHONPATH environment variable must be set up correctly to find these packages)
• In this case, these files are minimal and contain only glue code that specifies what should be used and where the implementation is.

SEE ALSO:

• Step-library concept: features/step.use_step_library.feature

OTHERWISE:

• You could provide your own Runner class and use it (but I would advise against it; reason: Nobody but you will understand where the steps/environment come from).

[monicalicareti]

Thank you for the quick answer.

Based on the link you shared, I came up with this:

sw_repository
|- tests
    |- unit_tests
    |- xil_tests
        |-features
        |-steps 
            |-python_steps_implementation   <--- git submodule
            |-load_step_libraries.py 
        |-environment.py

I like this because it's easily extendable with other submodules.
I don't like this because it still forces me to leave the environment.py and now load_step_libraries.py in the SW repository, rather than in the test automation repository. I could do all the imports in environment.py and get rid of load_step_libraries.py, but still I would have the environment.py in the SW repo rather than the test repo.

Is there a plan for behave to allow this separation between features and steps in the future?

[jenisys]

• The current solutions is already minimal in my opinion because it allows you to import all steps and environment-file contents from any Python package(s).
• The glue code is necessary that anybody else can understand where things come from.

Currently, there is no plan to change this (because a minimal solution already exists).

NOTE:
Your git-submodule does not need to be in the steps/ directory. It can be anywhere. You just need to put it in the PYTHONPATH environment variable (or setup the sys.path correctly in the glue code files).

[bittner]

Can you share or explain what is in your load_step_libraries.py module? The name suggests that the solution is a hack.

In my point of view, the test setup should be both elegant and easy to understand.

1. I consider a setup with Behave "elegant" when
   • the steps folder contains the bare minimum to implement what is specified in features,
   • distracting implementation details of the steps code are in (one or more) steps libraries, and
   • the environment.py is outside of features and steps, as you have it now (because it defines execution details - not the details of the feature steps).
2. I consider the setup "easy to understand" when changes in the features and the steps directories coincide, i.e. when adding or changing a test (detail) is visible in a single commit. So, while it may be a good idea to keep a step library in a separate repository, feature files and step implementation should be in a single one.

Just my two cents.

[monicalicareti]

Hi bittner,

The load_step_libraries.py only contains a series of imports like from python_steps_implementation.feature1_steps import *.
I agree that the features and steps should be in the same place since they are tightly coupled. However, it was the project's decision to keep the features (ie. tests) in the sw repository (there's a Test folder where they want to group all tests). I am just trying to accommodate this.

I do try to keep the step implementation as lean as possible and not put heavy logic in, but rather in dependency classes that I can test more easily. (for the moment it's not clear to me how I could unit test my steps)

[jenisys]

HINT:

• behave.ini: paths are for default arguments (features) if behave is run without command-line arguments. Therefore, it is not doing what you thought it would be doing.