-
Notifications
You must be signed in to change notification settings - Fork 45
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
Test Case(s) #22
Comments
This is a pretty interesting idea, thanks for opening an issue and providing some of your work. Definitely my least favorite part about the design of the package is how much boilerplate is required to setup the required fixtures, and if we could move more of that to command line flags or pytest config values then it'd make the package a lot more useable. Still, I don't have a good handle on what the implications would be of switching to this approach, particularly in terms of the tradeoff inherent in abstracting away database setup and the feasibility of supporting multiple database engines. I'll have to spend some time digging in before I can say definitively if this is an area I'm interested in. |
Dear Ms. Cochrane,
The main idea here is that some one using your package can pull the test
suite and run it against whatever database they are using. Providing a
quick diagnostic for them to test their setup. To my knowledge, because it
is all using SQLAlchemy under the hood, it's simply a matter of changing
the database URI to try out different databases.
Could you setup a separate branch called `test-suite` or some similarly
named branch that i could createa pr against. Otherwise a separate
repository for such a test suite might be handy for me to push into. I'll
document what I have so far and push it up accordingly.
Presently I'm testing against Microsoft SQL. I will likely switch to
PostgreSQL in the near future to but that depends on the direction of my
current project.
|
Dear Ms. Cochrane,
I see in some of the other issues that you typically ask for the users to run their tests against PostgreSQL. I though it might be prudent for the project to provide a branch of PyTest-Flask-SQLAlchemy that provided a standard test that users could run against their own database. One could point users with issues to the test and ask them to run it first when reporting an issue. I have provided the code for such a test in my fork on a branch called testing.
Github, to my knowledge, does not allow one to create a PR pushing a branch from one repository to another, so you would have to pull this across if you wanted it for the project.
To make testing PyTest-Flask-SQLAlchemy as convenient as possible I have added a command line interface to the testing suite that creates a database and populates the schema prior to one running the tests and then removes it afterwards. The tests themselves take an additional argument that specifies the database so that this is not hard coded. So a typical use case would be as follows :
Regards,
Carel van Dam
The text was updated successfully, but these errors were encountered: