[TIP] Disable keyboard shortcuts in html coverage reports?

Ben Finney ben+python at benfinney.id.au
Tue Mar 4 17:39:54 PST 2014


Thomi Richards <thomi.richards at canonical.com> writes:

> As discussed on IRC, the root problem here twofold:
>
>    1. coverage, when copying static files to the html report dir will look
>    in the system path (/usr/share/javascript) for the files it wants, and will
>    prefer those files over the ones it bundles locally.

Right. In an OS with updates for packages, this is the preferred
behaviour: A new library (like ‘jquery.hotkeys.js’) should be
automatically used, instead of needing explicit upgrade in every package
that uses it.

>    2. The jquery-hotkeys JS files that are shipped in trusty have changed,
>    and are no longer compatible with coverage.

That's a problem in communication, IMO. If the changes in the library
are backward-incompatible, the library developer is not properly
communicating these changes to dependent developers.

> It seems like the options to fix this are:
>
>    - Make coverage use it's locally bundled files always. I.e.- _never_
>    look in /usr/share/javascript

This was deliberately added to behave properly on a package-managed OS
(such as Debian and derivatives), so I would expect that behaviour to
remain, for all the third-party JS libraries.

>    - Try and roll back the jquery.hotkeys changes in trusty.

The missing option, and the preferable one IMO, is:

* Find out what changes in the library broke Coverage; fix Coverage so
  it works with the latest published library.

> Let me know which solution you prefer, and I'll see if I can fix things up.

I'm aware that many JS developers don't seem to care much about breaking
existing dependent code with new updates, but I don't think that is a
reason to accept the status quo.

-- 
 \     “I used to think that the brain was the most wonderful organ in |
  `\   my body. Then I realized who was telling me this.” —Emo Philips |
_o__)                                                                  |
Ben Finney




More information about the testing-in-python mailing list