Re: [BUG] ob-sql.el: probably an extra paren

[Bastien <bzg@altern.org>]

Hi Achim,

Achim Gratz <Stromeko@Nexgo.DE> writes:

>> If anyone knows how to setup an automated tests framework for Org,
>> feel free to go ahead, we will use it and monitor broken tests to
>> see what's wrong in the code or in the tests or in the environment
>> running the tests.
>
> We already have one, 

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 Nick and Sebastien are asking is not to push
> commits that are known to not pass the tests.

This I 100% agree with.  I don't push commits that are known to me as
not passing the tests :)

>> Testing is a nice habit to have, but let's not make it a coercive
>> pre-requisit before pushing patches.
>
> Why not?  Any broken commits make automatic bisecting impossible and they
> are a constant source of irritation for folks who forget to test their new
> Org pulls before using or installing them.
>
>> My whole thinking here is well captured by Rich Hickey:
>
> The citation you gave doesn't even apply to the question at hand.  It is
> about writing tests, not using the tests you already have.

It is about life being short and time being spent on testing vs
coding.

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.

Rich message wrt tests is: "Life is short, decide whether you want to
spend it on testing or coding" -- so I think it's relevant here.  

I often have only 10 minutes at hand, make a few trivial changes, and
push.  For me, a mandatory pre-push hook running the test suite would
be a useless burden for 50% of my commits.  This would irritate me.

We might agree to disagree on this.

-- 
 Bastien