[openlp-dev] Moving to pytest fixtures

[Benjamin Hoving]

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 [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 <benjamin.hoving at gmail.com> 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 <johnathan.morris.58 at gmail.com> 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 <benjamin.hoving at gmail.com [mailto:benjamin.hoving at gmail.com]> 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 <openlp-dev at openlp.io [mailto:openlp-dev at openlp.io]> 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
raoul at snyman.info [mailto:raoul at snyman.info]
_______________________________________________
openlp-dev mailing list
openlp-dev at openlp.io [mailto:openlp-dev at openlp.io]
https://lists.openlp.io/mailman/listinfo/openlp-dev [https://lists.openlp.io/mailman/listinfo/openlp-dev]

_______________________________________________
openlp-dev mailing list
openlp-dev at openlp.io [mailto:openlp-dev at openlp.io]
https://lists.openlp.io/mailman/listinfo/openlp-dev [https://lists.openlp.io/mailman/listinfo/openlp-dev]

_______________________________________________ openlp-dev mailing list openlp-dev at openlp.io https://lists.openlp.io/mailman/listinfo/openlp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openlp.io/pipermail/openlp-dev/attachments/20191009/705cf49a/attachment.html>