Hum TestMixin was to provide a simple helper. A good case to be converted to a fixture(s)
The code above was created for a good reason but for the life of me I cannot remember as it was a few years ago. On Wed, 9 Oct 2019 at 20:10, Benjamin Hoving <[email protected]> wrote: > Just a quick follow up for finding other places where the QApplication > object is created. > > I just one other place in the testing code (other than the TestMixin > class): > > https://gitlab.com/openlp/openlp/blob/master/tests/functional/__init__.py#L28 > This line is run any time the module path is imported which would explain > why the QApplication object code in the TestMixin class never creates a new > object, but always reuses an existing object. > > - Ben > > On 10/8/2019 9:55:24 PM, Benjamin Hoving <[email protected]> > wrote: > 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]> > 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]> 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] >> _______________________________________________ >> 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 >> > _______________________________________________ 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 > -- Tim and Alison Bentley [email protected]
_______________________________________________ openlp-dev mailing list [email protected] https://lists.openlp.io/mailman/listinfo/openlp-dev
