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)
- How do you remember your first encounter with behave-django? Was it easy to get started?
- Did you ever try to run your tests with
behaveorpython manage.py testin the terminal? How did you find out aboutpython manage.py behave? - Anything else you remember to be missing or irritating about the content of the documentation?
- Getting confused when googling and seeing behave-django and django-behave (the latter I had used before). Only annoyance with getting started was figuring out how to change the directory of my features (it can be done via .behave file or in tox.ini with
[behave] paths=my/dir/for/features - Used both I think; the latter learned about in docs
- just the above issue I mentioned
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 1I'm using docker for my django app and executing behave using this Makefile file
behave:
docker-compose run --rm web python app/manage.py behavethis is my project's structure
Makefile
app/
features/
__init__.py
steps/
__init__.py
tutorial.py
tutorial.feature
manage.pyI'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!
