[LRUG] Testing PDFs

[Mark Burns]

Thanks all for the interesting ideas.

Jay, I like the idea of using flying saucer. Not sure about the
implementation of https://github.com/amardaxini/acts_as_flying_saucer if
that's what you mean. https://github.com/crispymtn/flying_ruby_saucer looks
a bit nicer.

Roland, I think you were correct about it not being the right fit. Still an
interesting idea worth knowing about.

Sam, that could work in tandem with the flying saucer approach.
I've probably invested a bit too much time to want to jump back to
generating HTML. My first attempt was using wicked_pdf and the underlying
renderer didn't support some of the things I needed to do.

Josh, I'm probably going to go with an approach like this maybe using some
of either Gerhard or Craig's ideas.
I think for me focusing on being able to generate individual components as
an entire pdf which I can diff against would be useful.
Possibly using diff-pdf in an iterative fashion until finding the
problematic pages, then components, then doing a visual diff on those.

On Wed, Aug 2, 2017 at 7:52 AM Jay Caines-Gooby <jay at gooby.org> wrote:

> We use acts-as-flying-saucer - it generates pdfs from erb & css, so rather
> than testing the pdf itself, you could test the generated xhtml that
> creates the pdfs...
>
> On 1 August 2017 at 20:00, Mark Burns <markthedeveloper at gmail.com> wrote:
>
>> Has anyone any recommendations or suggestions for testing PDF generation?
>>
>> I'm working on a side project and using Prawn. Which is great. I can
>> programmatically generate large aspects of the content I want.
>>
>> But so far I've been tweaking then looking at the result in the browser.
>> It's not an absolute nightmare - a few seconds to render. But it's hard
>> to know whether the result is working without actually looking at it.
>>
>> The DSL is nice, but very imperative. Mocking method calls out would be
>> insane.
>>
>> I'm managing to refactor into small objects to represent the components
>> and layout, pages, typography aspects etc of the document. Which brings the
>> complexity back down to manageable chunks.
>>
>> But ultimately everything just calls underlying prawn DSL methods. So I
>> can test little bits of logic that I have in my objects, but ultimately
>> whether it works or not comes down to "have a look and see".
>>
>> Perhaps the best I can hope for is screenshotting when I'm happy and
>> using approvals to verify each major change hasn't radically borked
>> everything.
>>
>> It seems like there are tools to test which strings get into the
>> document, but that seems like the easiest part. And probably the only part
>> I'd be happy with test doubles for prawn and setting expectations on the
>> text generating methods.
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>>
>
>
> --
> Jay Caines-Gooby
> http://jay.gooby.org
> jay at gooby.org
> +44 (0)7956 182625 <+44%207956%20182625>
> twitter, skype & aim: jaygooby
> gtalk: jaygooby at gmail.com
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20170802/b310c120/attachment-0002.html>