Feature Request: Artifact Links about spock-reports HOT 10 CLOSED

Pretty cool! I wonder if this feature cannot be implemented using your own template, based on the template framework I am implementing in next? If you think that's not possible, we can try to make this generic enough for other people to use it!

from spock-reports.

Looks to me like the template stuff is still in its early stages? I redid the stacktrace PR against next and it's all working but some template unit test is failing and it looks like it's just not fully written yet?

Will templates be something that are added to the html report or is the html report becoming a template as well and then everything's a template and then it'd just be a matter of me implementing my own template for a feature like this? Any docs on how templates are going to work? May make it easier for me to gauge the best way to introduce this back into your code base.

from spock-reports.

sorry, early stages... basically, I will make it easy for people to write their own templates. That means the HTML report could also be created using a template, but I chose not to change that for now. It can be done later, but will not add much value... the template I am writing as default creates a markdown report. The test is failing because it is not implemented yet, of course.
You can easily write your own HTML template once I am done.... but I need to finish it first.... I think I can finish in the next few days.... then I can document how it works. Will keep you posted...

from spock-reports.

that's interesting - I am working on a feature like this. Please checkout the grails film-strip plugin page to see what I mean: https://github.com/rdmueller/grails-filmStrip

as far as I can see, your artifacts are from geb. Geb generates them with each report statement. The grails geb extension also generates one at the end.

For Geb, there is a report listener with which you can extract the needed information. So does spock (which is used in this plugin). My goal is now to combine them in one listener in order to produce the merged information.

@Slugger : as far as I can see from your source, you are "guessing" the name of the artifacts from the information you got - does this still work with special characters in report names and with tests in several packages? I am just asking because these where the problems I got into and that's why I now use the GebReportListener (I guess that's the name)

from spock-reports.

Yeah it works with special chars because the folder I'm expecting artifacts to be written to for a feature method is the String.hashCode() of the feature name. So all names are converted to a long and that's the directory name I use. Special characters don't matter since I hash everything to a number.

I also don't use GebReporting since it's hard to configure where things get written to at the level of granularity I'm looking for. Instead, in the framework I'm writing, I've implemented my own subclass of GebSpec that handles all the path calculations then calls the screenshot and dom capture and ensures it gets written to where I want it to go.

from spock-reports.

So you've written your own framework?

from spock-reports.

Yeah, at work. My goal is to convince my employer to allow me to open source it, but that will be an uphill battle.

from spock-reports.

as I see, those artifacts are not directly related to spock, are they?

I think renato's approach is the right one - let's see if we can solve this through the template mechanism. Yes, it's not ready yet, but it's open source, maybe we can help and thus make this plugin even better.

Maybe this could be a way to convince your employer that open source is the right way :-)

from spock-reports.

No the artifacts are not related directly to spock. They are mostly from geb (screenshot, dom source) and then logs from other libs and tools called during the execution of the functional tests (client api logs into 3rd party systems, etc.).

Yeah, I'm all for trying the template approach, I have a private build that's working so people are "happy". But I just saw myself having to maintain this fork and lose out on enhancements (like templating for example) and just don't want to go down that route unless I absolutely have to. What i have works so there's no rush and I can definitely wait and see how this templating takes shape (and contribute to it as well hopefully). Originally I was trying to roll my own reporting into this framework of mine and then found this plugin, which was a blessing. I'm definitely all for contributing to this going forward.

As for making my framework OSS... I wouldn't hold your breath but I really do plan on trying to make it happen (the red tape involved, as one might imagine, is suffocating to say the least). :)

from spock-reports.

Because this feature seems more appropriate for a template report to implement than core, hope you don't mind if I close this issue?

If you need more data than is currently available in templates to achieve what you need, just let me know.

from spock-reports.