[TIP] Disable keyboard shortcuts in html coverage reports?
Daniel Staple -X (dastaple - BSKYB at Cisco)
dastaple at cisco.com
Mon Mar 3 03:59:27 PST 2014
> From: testing-in-python-bounces at lists.idyll.org [mailto:testing-in-python-
> bounces at lists.idyll.org] On Behalf Of Ned Batchelder
> Sent: 03 March 2014 11:38
> To: Ben Finney; testing-in-python at lists.idyll.org
> Subject: Re: [TIP] Disable keyboard shortcuts in html coverage reports?
> On 3/2/14 10:32 PM, Ben Finney wrote:
> > Ned Batchelder <ned at nedbatchelder.com> writes:
> >> On 3/2/14 4:37 PM, Thomi Richards wrote:
> >>> I've managed to track the problem down to the 'jquery.hotkeys.js'
> >>> file. In Precise this is version '0.8', in trusty it's '0.8+'. […]
> >> This sounds like the problem is not in coverage.py at all, but in the
> >> jquery.hotkeys.js file it depends on? Perhaps Trusty shouldn't take a
> >> new version, or you can get in touch with the developer?
> > Ideally, you as the author of a library depending on
> > “jquery.hotkeys.js”, should communicate with the author of that
> > library to make sure newer versions continue to work with your dependent
> > If there are changes in the library (and changes so small they
> > apparently don't warrant an increase in the version string) that cause
> > dependent code to break, the library code and/or the dependent code
> > needs to be fixed.
> > Do you agree?
> Actually, as you know, I was in favor of having my own copy of these tiny
> jQuery libraries that I needed to make coverage.py work. You were in favor
> of applying the Debian philosophy of making everything a separate library, no
> matter how finely sliced. The theory was that I could automatically get fixes.
> Now I've automatically gotten bugs. I had a package that worked. Debian
> has a package that does not. Now I have to chase down the author? :(
> Who made the decision to upgrade the package in Debian?
This may sound ludicrous but:
* Packages have dependents in machine readable formats
* Dependents can have automatic test suites. I'd be surprised if coverage.py didn't.
* This could be run as automated testing with Travis or Jenkins.
* There are a number of free open source test infrastructure providers.
I am aware it is much more complicated than this and probably requires time to set up, but it wouldn't be unreasonable to suggest setting up a hook to trigger the coverage.py tests in Debian when the packages it depends on change. Perhaps when slicing so thinly - something like this is what would protect the packages from breaking like this.
More information about the testing-in-python