There is a new instance of browser and config created per test, so
modifying config in setupSpec() will only have for the first test method in
a spec. You might get more luck by putting that code in setup but there
still will be cases where that code might not be applied to a browser
instance, like for example when reporting is triggered from cleanupSpec. I
would therefore consider registering your custom reporter in your config
script like I initially suggested.

Marcin

On Mon, Jun 6, 2022 at 11:05 PM Nick Bensema <[email protected]>
wrote:

> Thanks, you've made it a lot clearer for me, and I think I'm getting
> close. I've created a custom reporter that extends ReporterSupport, with
> its own writeReport method that does its own thing and calls
> notifyListeners.  I created a constructor where I can pass the existing
> reporter, so in my setupSpec I have something like this:
>
> browser.config.reporter = new MyReporter(browser.config.reporter)
>
> I can even call methods, like when I've downloaded the file I want to
> test, I can call browser.config.reporter.setDownloadedFile(file) and the
> log statements say it's executing.  But when I test it by introducing a
> purposeful failure, it still calls the ordinary ScreenshotReporter and
> skips my code entirely, and once again I get a png of the download page.
>
> So, what am I missing, why might my reporter not be activating?
> On Thursday, June 2, 2022 at 12:22:30 PM UTC-7 [email protected]
> wrote:
>
>> Hi Nick,
>>
>> Sorry for a late reply.
>>
>> So for the reporting on multiple windows you can use a built-in
>> capability - MultiWindowReporter. I don't know when it was introduced but
>> it's definitely available in 4.1 because its usage is described in the
>> manual for that version, see
>> https://gebish.org/manual/4.1/#reporting-on-multiple-windows.
>>
>> With regards to your second requirement of triggering another report
>> before performing an action and doing the report proper I would suggest
>> implementing another `geb.report.Reporter` and then plugging it in together
>> with MultiWindowReporter via configuration in a similar way to the one
>> reported in https://gebish.org/manual/4.1/#reporting-on-multiple-windows.
>> I think you should be able to get ideas how to implement that reporter from
>> looking at the sources of MultiWindowReporter (
>> https://github.com/geb/geb/blob/master/module/geb-core/src/main/groovy/geb/report/MultiWindowReporter.groovy)
>> but let me know if you struggle with it and I will help out with some code.
>>
>> Thanks,
>> Marcin
>>
>>
>>
>> On Fri, May 27, 2022 at 9:39 PM Nick Bensema <[email protected]>
>> wrote:
>>
>>> It looks like Geb development has come a long way, so I'm trying to keep
>>> my codebase current, and I've tried a few times to run my tests with geb
>>> 4.1 instead of 3.4.1 -- baby steps on the way to 5.1.  So far, it won't
>>> even compile, and I need some help.
>>>
>>> The first problem I have is that I have several specs, both abstract and
>>> concrete, which try to override the `reportFailure` method, which no longer
>>> compiles. I know that I'm supposed to use testManager, but it's not quite
>>> obvious how to do it; there's very little documentation about it.
>>>
>>> First of all, I have a main abstract class that also overrides
>>> reportFailure(), because those tests all have two browser windows open, and
>>> I want to make sure to screenshot both of them.
>>>
>>> But also, sometimes I override reportFailure in a concrete test class,
>>> so that I can get screenshots of dialog boxes, and close them.  That method
>>> also calls super.reportFailure(), meaning both of my custom methods will
>>> run.
>>>
>>> So, given a test class that overrides reportFailure(), how do I move
>>> that method into a test manager object that the class can use?  and will it
>>> support the kind of inheritance I had before?
>>>
>>> Example of the kind of thing my method will contain: calling the main
>>> report function, doing stuff with page content, and calling the superclass
>>> method which might also be an override:
>>>
>>> @Override
>>> void reportFailure() {
>>>     if( page instanceOf DesignerPage ) {
>>>         if(preview.displayed) {
>>>             report "preview"
>>>             preview.close()
>>>         }
>>>     }
>>>     super.reportFailure()
>>> }
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Geb User Mailing List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/geb-user/d3a5566a-672e-433b-a9d2-322da900e12en%40googlegroups.com
>>> <https://groups.google.com/d/msgid/geb-user/d3a5566a-672e-433b-a9d2-322da900e12en%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Geb User Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/geb-user/7488922e-f26e-445c-a7bc-dc947ad1029an%40googlegroups.com
> <https://groups.google.com/d/msgid/geb-user/7488922e-f26e-445c-a7bc-dc947ad1029an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Geb 
User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/geb-user/CA%2B52dQSCNadbupFUnbS2dvwGvx-04u4N0ukXM1kFBC1tcnkdtA%40mail.gmail.com.

Reply via email to