I'm using behave to test my little Django app.
I've already created the file user_management.feature that contains also this Scenario:
Scenario: register
Given I can access registration form
When I put "doctor" in "username" field
And I put "tardisBlue" in "password" field
And I put "doctor@tardis.com" in "email" field
And I press the "Register" button
Then the registration is successful
And I am logged in
Everythig works fine.
The next feature I want to develop is in file project_management.feature:
Scenario: create a project
Given I am logged in
When I go to the home page
And I click on "Create new Project" link
And I fill the fields
| field | text |
| name | Save Gallifrey |
And I click on "Save" button
And I go to the home page
Then I see the project name in the project list
Now when I execute my test, behave executes the feature files in alphabetical order, so project_management.feature is executed first.
It raise an error in the first given, because the user has not been created yet.
I've tested renamin the first file in 01_user_management.feature to make it work.
Do you know a better solution?
Is there some configuration file where I can specify the order of the feature file?
Or can I tell that a Scenario needs another Scenario tu run first?
You should not make scenarios dependent on one another. It is absolutely possible to do this. I have multiple large and complex test suites with hundred of scenarios. No scenario of mine depends on another scenario having run before it.
When you have a large suite and there's a single scenario failing, it is extremely useful to be able to do:
behave -n 'failing scenario name'
This gets Behave to run only the failing scenario. Alternatively, there's the @wip tag that can do the same thing. However, if the scenario you want to test depends on another one, Behave won't automatically know that it should run the other scenario so you have a) to know the dependency and b) manually take care of selecting all scenarios that the one you really want to run depends on.
What I'd do in your situation (which is pretty much what I've done in the past) is implement a step Given I am logged in as .... I implement it with a regex so that I can use
Given I am logged in as an administrator
Given I am logged in as a regular user
Given I am logged in as a user with permissions to delete articles
The application I'm testing has its database preloaded with some test users that correspond to the cases above. (There's still a test for registering new users but that's independent from the preloaded users.) The Given I am logged in as ... step just logs the user in. It does not need to create the user.
One of the side benefits of doing this is that if you run your suite on a test service like Sauce Labs or BrowserStack and use Selenium, you can implement the Given I am logged in as ... step to save a lot of testing time. Each Selenium command in such a case requires a round-trip between your Behave test and the browser running on the test service, which can take significant time transiting through the Internet. Reducing the number of such interactions can make a huge difference in the time it takes to run a whole suite.