[TIP] Disable keyboard shortcuts in html coverage reports?

[David Stanek]

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:
> 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
> > 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
> 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?
> >
> > --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.
>
> Danny
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>



-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20140303/c447b142/attachment.htm>