Closed ocefpaf closed 7 years ago
Yknow I was just writing a test yesterday that was similar to this - wanted to make sure a known set was within a somewhat variable set. I was using something like:
assert set(["04044724", "04045500", "04046000", "04056500"]) < set(sorted([x.uid for x in collection.elements]))
which works, but then you lose the really nice py.test introspection into what elements differ. Wonder if there is another set comparison that gets that nice py.test stuff.
I don't mind losing the introspection there. But I am worried about the expected set versus the variable set. What if one of the expected is out of the question? These tests are susceptible to those issues because they are trying to access real server and I believe that is fine since it helps us access the servers changes too.
Ideally we should have a more robust set of unit tests and tests like this one would be in a allow_failures
section of Travis-CI.
BTW the 3 remaining failures seems to be related to the underlying packages and not pyoos
per se . At least I cannot see any code or file change that is responsible for those failures.
I will investigate this more later, but I believe we should not hold a new release any longer.
Agreed, @ocefpaf. Like I mentioned in https://github.com/ioos/pyoos/pull/71#issuecomment-265517266, having a set of tests hit live services is beneficial, but should be combined with parsing/processing a set of saved output in the test source too.
Not ready yet...