Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Peter Bittner
    @bittner
    The (differences of) the two projects are explained in the behave documentation. They are used differently, that's what they make attractive for different audiences.
    Peter Bittner
    @bittner
    Historically, for what I recall, @mixxorz started the project because he wasn't happy with the integration 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)
    Dolan Antenucci
    @pydolan
    Thanks for the helpful resources Peter!
    Peter Bittner
    @bittner
    Want to review some test code? Take a look at issue #73! -- Interesting code with freezegun and mail.outbox.
    Faran Negarestan
    @faran-mw
    Hello all, I'm starting to use behave (1.2.6) and behave-django (1.1.0) with Django 2.1.7 (python3) within PyCharm. The issue I'm seeing is when I run the tests using "manage.py test" command, all behave and non-behave tests run successfully. However, I get an "sqlite3.IntegrityError: FOREIGN KEY constraint failed" exception at the every end in the teardown step. has anyone ever experienced this issue before ?
    Peter Bittner
    @bittner
    A quick survey on our documentation:
    1. How do you remember your first encounter with behave-django? Was it easy to get started?
    2. Did you ever try to run your tests with behave or python manage.py test in the terminal? How did you find out about python manage.py behave?
    3. Anything else you remember to be missing or irritating about the content of the documentation?
    Dolan Antenucci
    @pydolan
    1. 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
    2. Used both I think; the latter learned about in docs
    3. just the above issue I mentioned
    Dolan Antenucci
    @pydolan

    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)
        )
    Peter Bittner
    @bittner
    And THEME_ADMIN_URL is defined in your Django settings?
    Dolan Antenucci
    @pydolan
    @bittner -- My bad, setting this variable addresses the issue. There is probably some other reason other than behave-django why the undefined error started showing up. Thanks!
    Dolan Antenucci
    @pydolan
    Can you issue a new release with the decorator-fixture fix? https://github.com/behave/behave-django/pull/72/files
    Peter Bittner
    @bittner
    This is pending. I've written @mixxorz about it (by email), no answer yet. We need him to do this, no-one else has owner permissions on PyPI, unfortunately. And automating the release process via Travis CI is only on the TODO list. :worried:
    Dolan Antenucci
    @pydolan
    Okay, thanks. I'll pull from github for now :)
    Peter Bittner
    @bittner
    Peter Bittner
    @bittner
    behave-django v1.2.0 is out! :loudspeaker:
    Dolan Antenucci
    @pydolan
    Is there a good way to apply certain Django Settings for a particular scenario/feature, similar to how fixtures can be loaded?
    Peter Bittner
    @bittner
    This is still an unsolved issue. See behave/behave-django#13
    It would be nice if we could find a solution, preferably one that feels just like Django.
    Vincent Lortie
    @vincent.lortie.sgx_gitlab

    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

    Dolan Antenucci
    @pydolan

    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.

    Vincent Lortie
    @vincent.lortie.sgx_gitlab

    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.

    Vincent Lortie
    @vincent.lortie.sgx_gitlab
    In the behave docs, the section about composite fixtures seems to address my issue, but I was wondering if I was missing something
    jenisys
    @jenisys
    Fixture setup and cleanup are symmetric If you register/setup a fixture in the before_scenario hook, or will cleaned update after this scenario. If you register/ setup the fuxture in the before_all hook, or will be cleaned up after_all hook is called.
    Vincent Lortie
    @vincent.lortie.sgx_gitlab
    So if I declare django fixtures in the before_scenario method, in theory, I should not have to do anything and the fixture is torn down after the scenario by default ?
    Dolan Antenucci
    @pydolan
    One thing to note with declaring fixtures in 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
    Vincent Lortie
    @vincent.lortie.sgx_gitlab
    Right ! I've tried extensive combinations with this variable, trying to put it empty in the 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.
    Dolan Antenucci
    @pydolan
    I personally prefer to include my scenario-specific fixtures with the fixture wrapper (https://behave-django.readthedocs.io/en/stable/usage.html#fixtures-using-a-decorator), mainly because I like how it organizes the code, but it also avoids having to reset context.fixtures when setting fixtures in before_scenario.
    jenisys
    @jenisys
    Sorry, I am talking about how the behave fixture mechanism is working.
    Vincent Lortie
    @vincent.lortie.sgx_gitlab

    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.

    Vincent Lortie
    @vincent.lortie.sgx_gitlab

    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

    Peter Bittner
    @bittner
    Cool! The feature obviously comes from Django itself. See https://docs.djangoproject.com/en/stable/topics/testing/overview/#rollback-emulation
    Vincent Lortie
    @vincent.lortie.sgx_gitlab
    @bittner @jenisys @pydolan Thanks for your help !
    Vincent Lortie
    @vincent.lortie.sgx_gitlab

    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 !

    Gaurav-t
    @Gaurav-t
    Hi All, I am new to django-behave, I got stuck at a point where I need to consider the a celery task which get triggered from a view. Right now I am using "celery_always_eager=True" which would run celery tasks at once just like a normal function, but this time I am dealing with a celery task which get should get triggered on at a definite time interval(say 1 minute). Is there a more appropriate way to integrate celery with behave? Thanks in Advance :)
    Peter Bittner
    @bittner
    @Gaurav-t Your question is not specific to Django, correct? Note that there is also a general behave/behave Gitter room. You may get an answer faster over there.
    Gaurav-t
    @Gaurav-t
    @bittner Thanks for your suggestion. I'll ask on the mentioned Gitter room :)
    Iván Fernando Casanova
    @icnovaro

    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.

    Iván Fernando Casanova
    @icnovaro
    But when I enter in the web container and execute behave's command it works
    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'...
    jenisys
    @jenisys
    Make (I am assuming GNU make) has also some debugging features, like make —debug ... (AFAIK). Check the make docs. Otherwise, provide echo statements in the Makefile to better trace where the fault location in the makefile (or the docker container) is.
    Peter Bittner
    @bittner
    This sounds very much like an issue of the Docker Compose setup. Can you provide the related source code, i.e. your 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?
    Iván Fernando Casanova
    @icnovaro
    Well, finally I found a solution, it seems that the 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'
    Peter Bittner
    @bittner
    @jenisys Can you turn off the "Wiki" feature on the behave-django repository, please? (Or give me permissions to do so.) -- Thank you in advance!
    Peter Bittner
    @bittner
    behave-django v1.4.0 released! :confetti_ball: Now with page object helpers to make you test code easier to read and maintain! Phases out deprecated multi_db option in favor of databases. Feedback welcome!
    jenisys
    @jenisys
    @bittner Both done
    Peter Bittner
    @bittner
    Nice! Thank you!
    Now, what's missing is that you press the Merge button in behave/behave#795 :smirk:
    Javier Buzzi
    @kingbuzzman
    ^ LOL
    @bittner i really do appreciate you championing this :D
    Bren Eser
    @breneser

    Hey all,

    Quick question, is there a way to change the host of tests running?

    I have a docker setup with my project and behave-django uses localhost as the host. I need to set it to web which is the docker-compose service name of the web app

    Peter Bittner
    @bittner
    Are you talking about the value of context.base_url? You can simply override the value, if needed. Should be simple to do.