Re: [PATCH v2 9/9] Test read_early_config()

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 3, 2017, 15:04 UTC
Message-ID: <alpine.DEB.2.20.1703031553070.3767@virtualbox>
In-Reply-To: <20170303050745.wv4zsb24ykr34xr7@sigill.intra.peff.net>

Hi Peff,

On Fri, 3 Mar 2017, Jeff King wrote:

Show 6 quoted lines

> On Fri, Mar 03, 2017 at 03:04:36AM +0100, Johannes Schindelin wrote:
> 
> > So far, we had no explicit tests of that function.
> 
> Makes sense. The pager tests fixed in an earlier commit were effectively
> checking those, but I don't mind making it explicit.

Well, TBH I am a bit uncomfortable with t7006 doing those tests. Just imagine that something breaks in that script, say, when working on exporting the read_early_config() function. You probably see this coming: debugging those breakages is half a nightmare. There are multiple levels of shell script functions, a Perl script, and an isatty() call between the bug hunter and the bug.

With the new tests, it all becomes much more straight-forward to debug. And also less surprising (think about the fun you can have with test cases that fail when running `make t7006-pager.sh` but not when running `bash t7006-pager.sh -i -v -x`, just because of a forgotten `test_terminal`...).

And yes, you can debug t7006 with the good old "insert debug print statements here and there, then compile and run, rinse & repeat" method. But you know, getting to use a real IDE with real debugger/intellisense integration after years of working on C code in the terminal with vim and gdb [*1*], I kinda feel a bit pampered and ask myself how I could possibly have put up with the awkwardness. ;-)

Ciao, Dscho

Footnote *1*: for some years I developed Java code in Eclipse and already then did I notice just how much faster development becomes when you have powerful tools to help you...