That sounds similar. One odd thing in this scenario is that the currently
enabled tests don't cause the segfault, which means that something about those
tests is different from the ones that are currently disabled (TestOpenLP). The
only difference I can find is that the TestOpenLP class actually requires an
instance of OpenLP rather than a generic QApplication instance like what is
created in the TestMixin class.
The current TestMixin class has a setup_application method that attempts to get
the current QApplication instance and either reuses that instance if it exists
or creates a new one.
Another odd thing is that if I put a print statement that prints whether the
QApplication was reused or created in the TestMixin.setup_application method,
it never runs the 'created' branch - it always runs the 'reused' branch which
means that the QApplication object is being initially created somewhere other
than the TestMixin.setup_application method and then all calls to the
setup_application method use the 'reuse' branch because the QApplication object
already exists. I haven't figured that one out yet. I'm going to look into it
more later tonight and see if I can find where the object is being created.
All these tests are running on the current unittest tests from the master
branch with the pytest runner. The only thing I change is to make the
TestOpenLP class inherit from TestMixin (the tests crash with AttributeError's
if the class is not inherited.) and there is a call to patch that has an
outdated module path. I can publish the testing branch if that would be
helpful. Not sure if a merge request is appropriate if I don't actually have a
solution.
I think I had a branch at one point that had the TestOpenLP tests running and
passing with the unittest test runner but not the pytest runner, but I'm not
sure if I kept that branch around.
- Ben
On 10/8/2019 6:51:48 PM, John Morris <[email protected]> wrote:
I ran into an issue like what you are describing....I created a workaround
using an underlying part of pytest that runs before the startup function to
creat a global variable. Then when startup ran it changed the state of the
variable and did not recreate the offending object....I know this is a
hack....but it might spark an idea.
On Tue, Oct 8, 2019, 6:32 PM Benjamin Hoving <[email protected]
[mailto:[email protected]]> wrote:
I haven't had a chance to try anything, but I think the fix for that would be
to call Registry().create() before each test, which could be done easily (and
even automatically, I think) from a fixture.
On 10/8/2019 6:29:07 PM, Raoul Snyman via openlp-dev <[email protected]
[mailto:[email protected]]> wrote:
On 2019-10-08 15:22, Benjamin Hoving wrote:
> The basic problem is that the QApplication object is only meant to be
> instantiated once for the lifetime of the application, which is what
> happens during the normal execution of OpenLP, but during testing, the
> QApplication is created and destroyed many times and references to the
> object may not always be torn down between tests. I personally suspect
> (though I have not had a chance to fully investigate) that the
> Settings object or some of the singleton objects may be keeping
> references to the QApplication object. (for instance, I know that the
> Registry singleton is explicitly given a reference to the QApplication
> object and I don't think the Registry object is destroyed between
> tests). This makes it very difficult to pinpoint the actual point of
> failure for a test because the point of failure may be caused as a
> side effect of another test failing to tear the environment down
> properly. (i.e. one that initialized the Registry and gave it a
> QApplication reference, but did not reset the Registry).
Aha. You might be onto something here. I'm not sure how well we reset
the Registry object, if at all, during tests.
--
Raoul Snyman
[email protected] [mailto:[email protected]]
_______________________________________________
openlp-dev mailing list
[email protected] [mailto:[email protected]]
https://lists.openlp.io/mailman/listinfo/openlp-dev
[https://lists.openlp.io/mailman/listinfo/openlp-dev]
_______________________________________________
openlp-dev mailing list
[email protected] [mailto:[email protected]]
https://lists.openlp.io/mailman/listinfo/openlp-dev
[https://lists.openlp.io/mailman/listinfo/openlp-dev]
_______________________________________________ openlp-dev mailing list
[email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev
_______________________________________________
openlp-dev mailing list
[email protected]
https://lists.openlp.io/mailman/listinfo/openlp-dev
