[openlp-dev] Moving to pytest fixtures

Wed Oct 9 15:18:32 EDT 2019

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 <benjamin.hoving at gmail.com>
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 <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>
> 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> 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
>> _______________________________________________
>> openlp-dev mailing list
>> openlp-dev at openlp.io
>> 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
>>
> _______________________________________________ openlp-dev mailing list
> openlp-dev at openlp.io 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
>

-- 
Tim and Alison Bentley
Home at TRARBentley.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openlp.io/pipermail/openlp-dev/attachments/20191009/3c18e9a6/attachment-0001.html>