Add config tests #399
Add config tests #399
Conversation
|
I have rebased onto the latest master which should make the test suite pass. |
|
I see the previously failing tests was masking some actual problems, and have a bit more work cut out for me with regards to dealing with python 3.5 and the permissions of the certificates on windows. |
|
The cert + windows problems seems to stem from the fact that |
Using NamedTemporaryFile seems to cause problems on Windows builds as they are not able to be reopened later on, instead it is possible to use the pytest fixture tmp_path to build more looking tmp files, and just return the filename, which works fine as only the names was being used anyway.
|
The windows build is still failing, this time when getting Judging from the logs on travis, there is an extra task spawned onto the loop for some reason and the mock loop only runs a single coroutine for those tests. It started happening after the change from I don't have a windows machine at hand to replicate this with, so if someone can see the connection between the changes I did and the test, I would be very happy to continue, but currently I am just hitting the wall here. |
|
CI failures in |
|
Oh yeah @jlaine that looks very similar, and indeed I can actually see a similar log line being spewed out when running the tests locally, although that does not make it fail for some reason (running Arch locally here with Python 3.7.4 and uvloop 0.13.0). |
|
I have submitted a tentative patch in #418. AFAICT the issue is that if the WSGI task raises an exception, the "sender" task (in charge of sending out response messages) is left dangling. |
|
Okay, probably worth merging master into this PR, and seeing where that gets us, right? |
* master: Relax uvloop version requirement to 0.* If the WSGI task blows up, allow the sender task to shut down
|
That seemed to do the trick. Very nice @jlaine! Now that it is actually passing tests, we can |
|
Lovely stuff! |
As mentioned in #102 there was a need for some more test coverage of the config class, which seems like a fairly lowing hanging fruit, possibly low enough that I could manage to pick it.
I used the latest codecov report of the class to see what lines was missing coverage and tried to target those as best I could. I went with the naive way of just asserting what the code returned, so it is not impossible (perhaps likely, even) that I am mistaken about the behaviour of the class.
Locally I have some failing tests in the
test_statreload.pyfile, but as I have yet to make any changes to the code itself, I suspect there where there when I cloned the repo. I could have a look at what those are, but I have barely looked past the config class.