django-behave
provided (I think this is mentioned in one of the closed issues or PRs of the original GitHub project, he may correct me if I'm wrong). I jumped on board for about the same reason. (mixxorz/behave-django#10)
behave
or python manage.py test
in the terminal? How did you find out about python manage.py behave
?[behave] paths=my/dir/for/features
I'm currently migrating from django-behave
to behave-django
, and I got an issue when my 2nd scenario runs, I immediately get an error from a 3rd party library (pinax-theme-bootstrap) about an undefined attribute (AttributeError: 'Settings' object has no attribute 'THEME_ADMIN_URL'
at this line). This error never surfaces otherwise, and after reviewing that library's code, I see no reason this issue should surface, so I'm wondering if you can think of any reason why the issue would surface for scenario 2, or if you have any ideas on how to debug further.
Here's my environment.py file:
from selenium import webdriver
def before_all(context):
context.fixtures = ['testing.json', 'user_data.json']
context.browser = webdriver.Chrome()
context.browser.set_window_size(1200, 900)
context.browser.implicitly_wait(1)
And my feature file:
Feature: Test Feature
Scenario: Visit 1
Given I visit "/accounts/login/"
Then I see the content "Please sign in"
Scenario: Visit 2
Given I visit "/accounts/login/"
Then I see the content "Please sign in"
And my steps/general.py:
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support.expected_conditions import text_to_be_present_in_element
@given('I visit "{url}"')
def go_to_url(context, url):
context.browser.get(context.get_url(url))
@then('I see the content "{text}"')
def then_i_see(context, text):
WebDriverWait(context.browser, 120).until(
text_to_be_present_in_element((By.TAG_NAME, "body"), text)
)
Hello, I was wondering if someone is comfortable explaining how fixtures with foreign keys are deleted in between scenarios.
This code raises django.db.utils.IntegrityError: foreign key constraint failed
def before_all(context):
context.fixtures = ['fixture_with_fk.json', 'fixture_without_fk.json']
Where as this one does not:
def before_all(context):
context.fixtures = ['fixture_without_fk.json']
I can provide a stack trace if it can help
In my experience, the fixtures in before_all
remain around, but all other database changes in a scenario are undone. However, my understanding of when the before-all fixtures are loaded and how transaction-wrapping is done could be wrong.
If you can provide more info, I'm happy to try to help.
Ok I will try to add more details. I am definitely a beginner with behave and behavioral testing, so I may miss trivial things.
My main hypothesis is that my fixture is not properly deleted on tear down after each scenario. For example, this works
def before_scenario(context,scenario):
if scenario.name == 'scenario1':
context.fixtures = ['fixture_without_fk.json']
elif scenario.name == 'scenario2':
context.fixtures = ['fixture_with_fk.json', 'fixture_without_fk.json']
whereas this code below raises django.db.utils.IntegrityError: foreign key
def before_scenario(context,scenario):
if scenario.name == 'scenario1':
context.fixtures = ['fixture_with_fk.json', 'fixture_without_fk.json']
elif scenario.name == 'scenario2':
context.fixtures = ['fixture_without_fk.json']
I've tried several things to try and understand the problem. When I use before_all, it's like the same fixtures are applied to each scenario (which is expected). It does seem like they always go through the process of being torn down at the end of each scenario (the exception is raised).
Also worth noting that I simplified my scenarios to a simple assert True
and the exception is really raised before the execution of the scenario itself.
before_scenario
-- even though it is probably unrelated to your above issue -- is that the context.fixtures
variable does not reset between scenarios, so it's best to have an else: context.fixtures = []
statement so that a "scenario3" does not have the fixtures set for "scenario2". More on this in docs: https://behave-django.readthedocs.io/en/stable/usage.html#fixture-loading
after_scenario
, and many other combinations. I think Monday I'm going to try and enter my fixtures manually. Perhaps there is a problem in one of models. I'll report back once I have more information.
I have experimented with the use_fixture
function in behave. So far I think this is what I was looking for. I feel like this section is what I needed out of behave-django.
@pydolan I got the same results with the wrapper, I do agree that the syntax improves readability !
@jenisys Thank you, I think I stumbled upon your point in this section.
I actually stumbled upon this link and it seems like setting BehaviorDrivenTestCase.serialized_rollback = True
did the trick with my django fixtures
Relevant issue:
behave/behave-django#4
Quick update and conclusion:
We had a django object that was being created in a migration. This object was a foreign key for some fixtures. Therefore, the FK from migrations was not available for scenario 2. Setting BehaviorDrivenTestCase.serialized_rollback = True
allowed us to access this FK for each scenario.
We may just move the object creation to a fixture to avoid the grief. Once again, thanks to all !
Hi you all,
I'm having this problem executing behave features.
ConfigError: No steps directory in '/code/features'
makefile:13: recipe for target 'behave' failed
make: *** [behave] Error 1
I'm using docker for my django app and executing behave using this Makefile file
behave:
docker-compose run --rm web python app/manage.py behave
this is my project's structure
Makefile
app/
features/
__init__.py
steps/
__init__.py
tutorial.py
tutorial.feature
manage.py
I've already tried sending the feature uri in the behave args and I did't work.
python manage.py behave
Creating test database for alias 'default'...
Feature: showing off behave # features/tutorial.feature:1
Scenario: run a simple test # features/tutorial.feature:3
Given we have behave installed # features/steps/tutorial.py:3 0.000s
When we implement a test # features/steps/tutorial.py:7 0.000s
Then behave will test it for us! # features/steps/tutorial.py:11 0.004s
1 feature passed, 0 failed, 0 skipped
1 scenario passed, 0 failed, 0 skipped
3 steps passed, 0 failed, 0 skipped, 0 undefined
Took 0m0.004s
Destroying test database for alias 'default'...
docker-compose.yml
file? Also, how do you "enter in the web container"? Is it with docker-compose run --rm -it web bash
or docker-compose exec web bash
, or something else?
behave
command search the features folder right in the actual folder where we're making the shell statement so I changed the makefile behave command for something like that:behave:
docker-compose exec web bash -c 'cd app && python manage.py behave'
multi_db
option in favor of databases
. Feedback welcome!