I did indeed fix that problem by moving it to just setup() -- moving it to the config isn't yet appropriate because I want to report different test classes differently; I have different tests for the UI and for the downloads. Maybe that will work if I can figure out how to modularize this project, but that's another thread...
Now I'm having a different problem with the MultiWindowReporter. It's writing the HTML and PNG for both windows, but only one of them is showing up in my geb-spock-reports output -- always the same one, the main window rather than the editor window. If I add an extra report "notFailure" call in my test, both reports show up, but still only the first window. I went so far as to upgrade to Spock 2.0 and Groovy 3.0, but ended up right back where I started. For what it's worth, I went from version 1.8.0 to version 2.0-groovy-3.0 of this: https://github.com/AOEpeople/geb-spock-reports I thought it might have to do with the long window name or the space in the name or something, so I tried writing my own writeWindowReport call. I'd need to do this anyway because "main" and "design" will be more helpful names than the window ID. My reporter correctly determines the correct window label, writes the logging message, and writes both HTML and PNG files for each one, but only the "main" shows up in the HTML report for that test class: class DesignerReporter extends MultiWindowReporter { public DesignerReporter(Reporter r) { super(r) } void writeWindowReport(ReportState reportState, String windowId) { //geb.Browser browser = reportState.browser reportState.browser.withWindow(windowId) { def windowLabel = "${reportState.label}.main" if(isAt(DesignerPage)) { windowLabel = "${reportState.label}.designer" } log.info "reporting $windowLabel with window $windowId" def windowState = new ReportState(reportState.browser, windowLabel, reportState.outputDir) backing.writeReport(windowState) } } On Friday, June 10, 2022 at 12:35:41 AM UTC-7 marcin....@proxerd.pl wrote: > 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 <nick.ben...@gmail.com> > 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 marcin....@proxerd.pl >> 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 <nick.ben...@gmail.com> >>> 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 geb-user+u...@googlegroups.com. >>>> 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 geb-user+u...@googlegroups.com. >> > 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 geb-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/6ebb74e9-92ee-4887-a3f1-c73fc0bfceb0n%40googlegroups.com.
