Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
livserver never loading the fixture data #8
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?
We worked around this issue, but it would be great if the documentation and plugin assisted with these problems.
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.
P.S. I'll be writing a full blog post documenting how to set this beast up. It's cost far too much time.
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?