<div dir="auto">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 8, 2019, 6:32 PM Benjamin Hoving <<a href="mailto:benjamin.hoving@gmail.com">benjamin.hoving@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id="m_-4934852301326588340__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:#000000">
                                        
                                        
                                            
                                        
                                        
                                        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.<div></div>
                                        
                                        <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
                        <p style="color:#aaaaaa;margin-top:10px">On 10/8/2019 6:29:07 PM, Raoul Snyman via openlp-dev <<a href="mailto:openlp-dev@openlp.io" target="_blank" rel="noreferrer">openlp-dev@openlp.io</a>> wrote:</p><div style="font-family:Arial,Helvetica,sans-serif">On 2019-10-08 15:22, Benjamin Hoving wrote:<br>> The basic problem is that the QApplication object is only meant to be<br>> instantiated once for the lifetime of the application, which is what<br>> happens during the normal execution of OpenLP, but during testing, the<br>> QApplication is created and destroyed many times and references to the<br>> object may not always be torn down between tests. I personally suspect<br>> (though I have not had a chance to fully investigate) that the<br>> Settings object or some of the singleton objects may be keeping<br>> references to the QApplication object. (for instance, I know that the<br>> Registry singleton is explicitly given a reference to the QApplication<br>> object and I don't think the Registry object is destroyed between<br>> tests). This makes it very difficult to pinpoint the actual point of<br>> failure for a test because the point of failure may be caused as a<br>> side effect of another test failing to tear the environment down<br>> properly. (i.e. one that initialized the Registry and gave it a<br>> QApplication reference, but did not reset the Registry).<br><br>Aha. You might be onto something here. I'm not sure how well we reset <br>the Registry object, if at all, during tests.<br><br>-- <br>Raoul Snyman<br><a href="mailto:raoul@snyman.info" target="_blank" rel="noreferrer">raoul@snyman.info</a><br>_______________________________________________<br>openlp-dev mailing list<br><a href="mailto:openlp-dev@openlp.io" target="_blank" rel="noreferrer">openlp-dev@openlp.io</a><br><a href="https://lists.openlp.io/mailman/listinfo/openlp-dev" target="_blank" rel="noreferrer">https://lists.openlp.io/mailman/listinfo/openlp-dev</a><br></div></blockquote></div>_______________________________________________<br>
openlp-dev mailing list<br>
<a href="mailto:openlp-dev@openlp.io" target="_blank" rel="noreferrer">openlp-dev@openlp.io</a><br>
<a href="https://lists.openlp.io/mailman/listinfo/openlp-dev" rel="noreferrer noreferrer" target="_blank">https://lists.openlp.io/mailman/listinfo/openlp-dev</a><br>
</blockquote></div>