Re: Use of Python Imaging Library in tests

Hi James, thanks for the heads up,
I'm responding inline.

On Thu, Jun 4, 2015 at 10:56 AM, James Graham <james@hoppipolla.co.uk>
wrote:

> It looks like a number of the new referrer-policy tests are trying to use
> the Python Image module, which isn't part of the stdlib. As a result these
> tests aren't possible to run out of the box, which is new and problematic..
> Even if we shipped PIL (or Pillow) as part of the repository I believe that
> it has a build step, so tests would continue to not work out of the box.
>
> Can we find some alternative solution like checking in the generated files
> needed rather than trying to generate images at runtime? Otherwise I will
> end up disabling these tests on the Gecko infrastructure, which won't help
> anyone.
>

I have suppressed and removed the image tests for the time being. An open
PR is awaiting. The reason why we're not serving static images is due to
the fact we are encoding data into the image itself as (e.g. the headers we
receieve in the test) and then return back that data encoded as color which
we read from the canvas.

I'm aware this was an open issue and will try to workaround the PIL.Image
module, maybe just create a PNG encoder inline and use that instead.


> On a somewhat related note, there seem to be 1500 new files containing
> referrer-policy tests. This is somewhat slow to run. Are we sure that there
> isn't some way to set up these tests that's faster? I understand that there
> might not be, but I want to check.
>

I believe individual tests shouldn't be slow to run, only the sheer number
might be problematic in that sense. We're also looking into ways to reduce
the number of tests, e.g. we can suppress some redundancy in the near
future.


-- 

*Kristijan Burnik*

Software Engineering Intern

burnik@google.com

Google Germany GmbH

Dienerstraße 12

80331 München

Geschäftsführer: Graham Law, Christine Elizabeth Flores

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg