Added unit test configuration in gitlab-ci
This merge adds a unit-test gitlab-CI configuration based on pytest-django.
Merge request reports
Activity
@tanner.prestegard, you should be able to add the following as the regex for coverage parsing:
'/TOTAL.*\s+(\d+%)$/'@duncanmmacleod I've cherry-picked out your commit to add
lscsoft-gluein the requirements (it was previously installed via system packages) in order to sort out issues with it separately. Can you remove that commit and rebase off of master?added 7 commits
-
0e55db3e...1cc99c01 - 6 commits from branch
lscsoft:master - 0ea86150 - ci: added test jobs using pytest-django
-
0e55db3e...1cc99c01 - 6 commits from branch
@tanner.prestegard, done.
@duncanmmacleod I'm failing to understand the recent changes:
- I thought you're supposed to mock something "where it's used"? I haven't seen issues with the current arrangement of mocking
alerts.twilio_client. - No need to switch from
setUpTestDatatosetUp- we are using MySQL with MyISAM (i.e., non-transactional) sosetUpTestDatais actually run before each test (see the bottom of this section). - Why move the call to
super()insetUpClassto the bottom of the method? Doesn't that assume the base classes don't do anything which would change the parameters we are setting in the current class?
Not trying to be annoying, just want to understand!
- I thought you're supposed to mock something "where it's used"? I haven't seen issues with the current arrangement of mocking
I thought you're supposed to mock something "where it's used"? I haven't seen issues with the current arrangement of mocking
alerts.twilio_client.I will revert that change for clarity.
No need to switch from
setUpTestDatatosetUp- we are using MySQL with MyISAM (i.e., non-transactional) sosetUpTestDatais actually run before each test (see the bottom of this section).Ok, my issue is that I am using mysql=5.7 which requires that the
storage_enginereference be updated todefault_storage_engine. This will resolve a lot of my issues, I think.Why move the call to
super()insetUpClassto the bottom of the method? Doesn't that assume the base classes don't do anything which would change the parameters we are setting in the current class?For a number of classes the variables created in the new
setUpClassare required in thesetUpTestData()method, so thesuper()call (which will include the call tosetUpTestData()needs to come after those variables are defined.However, given your note above about non-transactional behaviour of django, this might be unnecessary.
