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
Enable testing with MySQL and Postgres on Travis-CI #171
Conversation
f486a3d
to
7f7b61b
Compare
7f7b61b
to
b9e8ab6
Compare
297333c
to
b9e8ab6
Compare
46121bb
to
cefa25a
Compare
cefa25a
to
6f9fdcd
Compare
6f9fdcd
to
e34804a
Compare
e34804a
to
1c2d2fd
Compare
f19200d
to
bad6c4c
Compare
1 similar comment
0a1158e
to
482f977
Compare
1 similar comment
1 similar comment
@tkdchen I think this is ready to merge so we can continue forward. I hate to merge with failing Postgres but MySQL, MariaDB and sqlite all work fine and some of the fixes are covered into other PRs. I don't think we have a lot of other options here otherwise this PR will become very big and there are other problems to worry about too. |
This is a big step forward to the testing. However, the problem is there is dependency of Travis in Nitrate source code, and this testing matrix cannot run locally by developer. I prefer to a solution to avoid these two major disadvantages. Basically, the testing matrix should
The second ability should be able to be used in Travis-CI to run the testing matrix. In my mind, docker would be a good tool to help us to build this testing matrix, and obviously some scripts would be required. Currently, to run whole test suite, I can simple run
It should be easy to make these steps happen in a docker container. Fedora 25 docker image can be used and it is ok to use the version of MySQL, MariaDB and PostgreSQL in Fedora repo. Finally, there could be these ways to run tests matrix
Thank you for making this improvement. It's valuable and develop our ideas. Let's make it better and better. I'll look at other commits in this PR from tomorrow. Have a good day. :) |
I think this can easily be done in the settings and then simply ask Travis to execute whichever command fits its matrix. In this way we move the infrastructure dependency in I will rework the settings for that. It is up to the developer to prepare their local environment for whichever DB they want to test on. I will also update the docs with commands how to install dependencies and run the tests against different databases. Note: vagrant or docker will be a great help but that's up to each developer to decide how to use. IMO this needs to come at a later stage because this PR is quite big already. What do you think? |
4888d77
to
bd74f39
Compare
@tkdchen see the updated documentation and the last 3 commits for the latest changes. It is not possible to execute the tests on the local machine by specifying which database to use. The same commands are integrated into Travis as well. All of the integration happens in .travis.yml. |
Using Travis to run tests does not mean there is a dependency of Travis to run tests. Simply say I don't want this line of code appears in source code
Documentation is good but not always. For running tests, I prefer to make it as easy as possible with just one command, no need of steps
Instead, as mentioned in my previous comment, just If someone is interested in the steps to build testing environment, just open and read the relative scripts. That should be more straightforward than lots of words in documentation and easy understand. |
bd74f39
to
61355c2
Compare
Mistake, this has now been updated. The rest (make test commands) are as requested and described in more details in the docs. Anything else missing ? |
61355c2
to
8b42d6f
Compare
@atodorov We talked a lot in IRC channel #nitrate. You did a good job to make it possible to run tests on different database engines. Hopefully, you could continue improving based on the changes in this PR to make running tests more easily. I'd like to repeat my thought again
Detailed documentation in this PR is good, I think it could be as reference for developers who are interested in hacking the tests for themselves. Is this clear and make sense? |
tcms/testruns/tests.py
Outdated
@@ -37,7 +36,7 @@ def setUpTestData(cls): | |||
cls.client = test.Client() | |||
|
|||
def test_404_if_run_does_not_exist(self): | |||
nonexisting_run_pk = TestRun.objects.count() + 1 | |||
nonexisting_run_pk = 999999 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be helpful to understand if you can add explanation to this change. Then, I'll merge it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, for some reason ( I think because PKs are global autoincrements on MySQL, generated via LAST_INSERT_ID())
TestRun.objects.count() == 1
nonexisting_run_pk == 2
but the only TestRun object in the database has an actual ID of 2 hence the failure!
On other DB engines the only TestRun object has an ID of 1. I will update this code with
TestRun.objects.last().pk + 1
which will be more robust.
However I have found one more thing. In testruns/urls/run_urls.py
there are two URLs which use the same view:
.../ordercase/$
and .../ordercaserun/$
. Do you know why is that? Sounds like a bug (let me know and I will send a separate PR for it).
Fix Nitrate#169 Signed-off-by: Mr. Senko <atodorov@mrsenko.com>
- the older Travis CI images have problems with MariaDB not picking up its configuration - also manually create DB and test DB and grant privileges to travis b/c connection will fail otherwise. Signed-off-by: Mr. Senko <atodorov@mrsenko.com>
On MySQL the default AutoField() translates to AUTO_INCREMENT which is shared between all tables! Signed-off-by: Mr. Senko <atodorov@mrsenko.com>
testing is now possible via the following commands: make test (uses SQlite) TEST_DB=all make test (will test on all DBs) TEST_DB=MySQL make test TEST_DB=MariaDB make test TEST_DB=Postgres make test In addition when preparing the local virtualenv we now have DB specific requirements files: requirements/mysql.txt (for MySQL and MariaDB) requirements/postgres.txt (for Postgres) requirements/base.txt (for SQLite) requirements/devel.txt (additional development libraries) Signed-off-by: Mr. Senko <atodorov@mrsenko.com>
Signed-off-by: Mr. Senko <atodorov@mrsenko.com>
also updates the usage of new requirements files Signed-off-by: Mr. Senko <atodorov@mrsenko.com>
8b42d6f
to
fa98cb2
Compare
Updated and rebased. @tkdchen let's move this comment #171 (comment) into a separate issue. I understand the value proposition of it and it is definitely doable even in the short term. However not everyone would like to follow exactly the same steps so we shouldn't force it. Plus a separate issue will allow us to discuss into more details. What do you think? |
1 similar comment
This was done in 2e22b8a and subsequent commits that make it possible to run with PostgreSQL. |
This PR enables MySQL and Postgres on Travis. I have a support ticket opened with their team to figure out how to add MariaDB alongside MySQL.
The build will fail b/c there are some issue with both MySQL and Postgres. I will try to fix them in subsequent commits.