Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

livserver never loading the fixture data #8

Closed
chris-hireiq opened this issue Aug 10, 2011 · 4 comments
Closed

livserver never loading the fixture data #8

chris-hireiq opened this issue Aug 10, 2011 · 4 comments
Assignees

Comments

@chris-hireiq
Copy link

We've got django-nose-selenium so close to working properly.

Really, everything works except for the loading of the test sqlite data for use by CherryPy. We determined that the default :memory: database was no good, so we're forcing sqlite to use a file.

However, it doesn't appear that the selenium_fixtures data gets loaded properly. Actually, we can get the test data to load and be visible to the actual selenium webdriver script, but the process running CherryPy can't seem to see that data when we go to perform operations against it.

Besides the selenium_fixtures configuration, is there anything else we need to do to get this working?

@chris-hireiq
Copy link
Author

We worked around this issue, but it would be great if the documentation and plugin assisted with these problems.

  1. SQLITE had an issue with using the default :memory: database for testing. CherryPy can't use that same database populated by the fixture populating mechanism. You need to set the TEST_NAME for the test database to an actual file in your settings.py.
  2. Additionally, you MUST use the Django TransactionTestCase as the base class for your Selenium test cases or else the initial fixture data is never persisted. Once you do that, there doesn't seem to be a point to using the selenium_fixtures parameter vs the regular fixtures one (although I didn't experiment too much to determine the differences).

@ghost ghost assigned passy Aug 17, 2011
@cpbotha
Copy link

cpbotha commented Aug 27, 2011

Thank you thank you thank you! I've been fighting for hours first with django-nose-selenium, then with django-sane-testing and now with django-nose-selinum again. Your tip on setting TEST_NAME to a real sqlite3 filename got everything working, in my case with a selenium_fixture. I did NOT need to use the TransactionTestCase.

Thanks again,
Charl

P.S. I'll be writing a full blog post documenting how to set this beast up. It's cost far too much time.

@cpbotha
Copy link

cpbotha commented Aug 27, 2011

For future reference, here's that blog post: http://blog.timescapers.com/2011/08/27/django-nose-selenium-a-concise-tutorial/

@passy
Copy link
Contributor

passy commented Aug 29, 2011

Awesome! I'm going to add a link to the README.

Thanks a lot!

@passy passy closed this as completed Aug 29, 2011
jdelamare added a commit to ereadingtool/ereadingtool that referenced this issue Nov 12, 2020
Removed what I thought was good user protection in the auth system we've
been creating. Looks like we'll go with minimal changes and try to break
it once it's running, rather than preventative. Here I'm referring to
checking the user's ID in the DB against the ID that was provided in the
JWT. Also, not sure if this matters (as it doesn't work on my machine
anyways) but there is a link to a very cryptic issue regarding SQLite3
and testing.

weluse/django-nose-selenium#8

This only has to do with selenium testing, and it doesn't seem to have
made a difference, but worth noting. Our tests may or may not work well
with the generated in-memory database created by Django. So we can use
`TEST_NAME` in settings.py to force more stable behavior apparently?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants