[TIP] Disable keyboard shortcuts in html coverage reports?
dstanek at dstanek.com
Mon Mar 3 05:50:18 PST 2014
In my opinion this would be a terrible waste of time for this case. To
really test this you would have to setup Selenium (or similar) to test in a
wide variety of OSes/Browsers. If the alternative is to bundle a handful of
known working JS files with coverage...why bother?
On Mon, Mar 3, 2014 at 6:59 AM, Daniel Staple -X (dastaple - BSKYB at
Cisco) <dastaple at cisco.com> wrote:
> > From: testing-in-python-bounces at lists.idyll.org [mailto:
> > 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
> > code.
> > >
> > > 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
> > of applying the Debian philosophy of making everything a separate
> library, no
> > matter how finely sliced. The theory was that I could automatically get
> > 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?
> > --Ned.
> 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.
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python