[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [BUG] ob-sql.el: probably an extra paren
From: |
Achim Gratz |
Subject: |
Re: [O] [BUG] ob-sql.el: probably an extra paren |
Date: |
Thu, 21 Mar 2013 18:38:24 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 |
Am 21.03.2013 14:41, schrieb Bastien:
The test are not automatic, they are manually triggered, so we don't
have an "automated tests framework" -- or am I misunderstanding what
an automated test framework is?
What you probably have in mind is a continuous integration framework
that triggers the test framework.
This I 100% agree with. I don't push commits that are known to me as
not passing the tests :)
The cavalier attitude is not funny, smiley or not.
It is about life being short and time being spent on testing vs
coding.
No, this is about doing it right or doing it twice.
I have a fairly slow machine, but running "make test" or even "make
test-dirty" with all tests enabled has not consumed an appreciable
amount of my lifetime and probably never will. It has however saved me
some pushes that had incomplete commits or some "obviously safe" last
minute changes that turned out not to be or triggered some unexpected
behaviour someplace else. I have also spent a good deal of time weeding
out false positives from bisects that could have been automated if one
could assume that each commit was always passing its tests.
If you can come up with a pre-push hook that is clever enough to
distinguish trivial-and-safe changes against those who need to be
tested, please submit one. A trivial-and-safe change is either:
- a change against non-code files;
- a change in docstring.
I don't think this is easy to do.
It is also a waste of time and not necessary. Simply run the tests on
each commit touching lisp/ and testing/ and reject the data from the
push if any test fails. Not sure if Jason wants to put this on the
server, though.
Regards,
--
Achim.
(on the road :-)
- Re: [O] [BUG] ob-sql.el: probably an extra paren, (continued)
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Yagnesh Raghava Yakkala, 2013/03/21
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Bastien, 2013/03/21
- [O] tests with travis-ci (was: [BUG] ob-sql.el: probably an extra paren), Yagnesh Raghava Yakkala, 2013/03/21
- Re: [O] tests with travis-ci, Bastien, 2013/03/21
- Re: [O] tests with travis-ci, Yagnesh Raghava Yakkala, 2013/03/21
- Re: [O] tests with travis-ci, Yann Hodique, 2013/03/22
- Re: [O] tests with travis-ci, Yagnesh Raghava Yakkala, 2013/03/22
- Re: [O] tests with travis-ci, Andreas Röhler, 2013/03/22
- Re: [O] tests with travis-ci, Nick Dokos, 2013/03/22
- Re: [O] tests with travis-ci, Andreas Röhler, 2013/03/22
- Re: [O] [BUG] ob-sql.el: probably an extra paren,
Achim Gratz <=
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Bastien, 2013/03/21
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Achim Gratz, 2013/03/22
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Bastien, 2013/03/22
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Achim Gratz, 2013/03/22
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Yagnesh Raghava Yakkala, 2013/03/22
- Re: [O] [BUG] ob-sql.el: probably an extra paren, Sebastien Vauban, 2013/03/21