git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Git List <git@vger.kernel.org>
Subject: Re: Git Test Coverage Report (Nov 25)
Date: Wed, 27 Nov 2019 09:33:44 -0500	[thread overview]
Message-ID: <59ae5223-6dd8-00cd-4c39-b307f8364457@gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1911262116100.31080@tvgsbejvaqbjf.bet>

On 11/26/2019 3:46 PM, Johannes Schindelin wrote:
> Hi Stolee,
> 
> thank you for keeping doing these reports.

Thanks for reading it!

> On Mon, 25 Nov 2019, Derrick Stolee wrote:
> 
>> Here is today's test coverage report.
>>
>> Sorry for the delay, but I had some issues working out the new
>> "ignored lines" logic. Now there are a few phrases that are
>> ignored automatically, including "BUG(" or "die(".
>>
>> [...]
>> Johannes Schindelin	eea4a7f4 mingw: demonstrate that all file handles are inherited by child processes
>> t/helper/test-run-command.c
>> eea4a7f4 203) static int inherit_handle(const char *argv0)
>> eea4a7f4 205) struct child_process cp = CHILD_PROCESS_INIT;
>> eea4a7f4 210) xsnprintf(path, sizeof(path), "out-XXXXXX");
>> eea4a7f4 211) tmp = xmkstemp(path);
>> eea4a7f4 213) argv_array_pushl(&cp.args,
>> eea4a7f4 215) cp.in = -1;
>> eea4a7f4 216) cp.no_stdout = cp.no_stderr = 1;
>> eea4a7f4 217) if (start_command(&cp) < 0)
>> eea4a7f4 221) close(tmp);
>> eea4a7f4 222) if (unlink(path))
>> eea4a7f4 225) if (close(cp.in) < 0 || finish_command(&cp) < 0)
>> eea4a7f4 228) return 0;
>> eea4a7f4 231) static int inherit_handle_child(void)
>> eea4a7f4 233) struct strbuf buf = STRBUF_INIT;
>> eea4a7f4 235) if (strbuf_read(&buf, 0, 0) < 0)
>> eea4a7f4 237) printf("Received %s\n", buf.buf);
>> eea4a7f4 238) strbuf_release(&buf);
>> eea4a7f4 240) return 0;
>> eea4a7f4 251) exit(inherit_handle(argv[0]));
>> eea4a7f4 253) exit(inherit_handle_child());
> 
> I think this is actually covered, but only in the Windows build.

Sorry that I have not set up a Windows build, but the Linux test-coverage
build already takes a long time so adding Windows would be complicated.
(Not to mention that merging the uncovered lines across two platforms would
be a huge challenge.)

If anyone wants to consider such an effort, I'm willing to play along.

>> Johannes Schindelin	116a408b commit: give correct advice for empty commit during a rebase
>> builtin/commit.c
>> 116a408b 478) else if (whence == FROM_CHERRY_PICK) {
>> 116a408b 479) if (rebase_in_progress && !sequencer_in_use)
>> 116a408b 1186) else if (whence == FROM_CHERRY_PICK) {
>> 116a408b 1187) if (rebase_in_progress && !sequencer_in_use)
> 
> My understanding is that Phillip is working on a replacement for this
> patch, so I'll leave this as-is for now.
> 
>> Johannes Schindelin	0de7b036 built-in add -i: offer the `quit` command
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	d17e3a76 built-in add -i: prepare for multi-selection commands
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	dea080c8 built-in add -i: re-implement `revert` in C
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	daabf56b built-in add -i: re-implement `add-untracked` in C
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	4ba7c22a built-in add -i: implement the `update` command
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	9d86921e built-in add -i: implement the `patch` command
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	a5ced6db built-in add -i: allow filtering the modified files list
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	465a9699 built-in add -i: re-implement the `diff` command
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	68db1cbf built-in add -i: support `?` (prompt help)
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	76b74323 built-in add -i: show unique prefixes of the commands
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	6348bfba built-in add -i: implement the main loop
>> add-interactive.c
>> [...]
>>
>> Johannes Schindelin	f83dff60 Start to implement a built-in version of `git add --interactive`
>> add-interactive.c
>> f83dff60 571) int run_add_i(struct repository *r, const struct pathspec *ps)
>>
>> builtin/add.c
>> f83dff60 197) return !!run_add_i(the_repository, pathspec);
> 
> This ginormous amount of code without test coverage is exactly the type of
> problem I pointed out with the approach I had to take in the built-in add
> -i/-p series, and which I described in the commit message
> https://public-inbox.org/git/5d9962d4344fa182b37cd8d969da01bc603414be.1573648866.git.gitgitgadget@gmail.com/
> Most of it _will_ be covered by the tests, but _only_ at the very end,
> when all six patch series will be merged.

I figured as much. When we have all six ready to go, then I can run a
"single branch" test for the feature against the base to see what is
uncovered from the entire effort.

>> Johannes Schindelin		rebase-merges: move labels' whitespace mangling into `label_oid()`
>> sequencer.c
>> 867bc1d2 4539) }
> 
> Not sure why this closing parenthesis isn't covered :-D
>
>> Johannes Schindelin	4d17fd25 remote-curl: unbreak http.extraHeader with custom allocators
>> http.c
>> 4d17fd25 417) string_list_clear(&extra_http_headers, 0);
> 
> I think it is okay to have that uncovered. This line is in the unlikely
> code path where a user will try to unset the extra headers via `git -c
> http.extraHeaders [...]`, i.e. without setting a value for that setting.
> 
>> Johannes Schindelin	2e0afafe Add git-bundle: move objects and references by archive
>> builtin/bundle.c
>> 2e0afafe 115) return 1;
> 
> I have to admit that I am slightly curious how this commit from 2007 ended
> up in this list: 2e0afafebd8 (Add git-bundle: move objects and references
> by archive, 2007-02-22). That's quite the blast of the past.
> 
>> Johannes Schindelin	116d1fa6 vreportf(): avoid relying on stdio buffering
>> usage.c
>> 116d1fa6 16) fprintf(stderr, "BUG!!! too long a prefix '%s'\n", prefix);
>> 116d1fa6 17) abort();
>> 116d1fa6 22) *p = '\0'; /* vsnprintf() failed, clip at prefix */
> 
> Those are defensive programming, so this is expected not to be covered.

I wonder why we are not using BUG() here (for the fprintf and abort).
 
>> Johannes Schindelin	d54dea77 fetch: let --jobs=<n> parallelize --multiple, too
>> builtin/fetch.c
>> d54dea77 113) fetch_parallel_config = git_config_int(k, v);
>> d54dea77 114) if (fetch_parallel_config < 0)
>> d54dea77 116) return 0;
>> d54dea77 1566) static int fetch_failed_to_start(struct strbuf *out, void *cb, void *task_cb)
>> d54dea77 1568) struct parallel_fetch_state *state = cb;
>> d54dea77 1569) const char *remote = task_cb;
>> d54dea77 1573) return 0;
> 
> I guess that yes, this points out that setting the number of parallel
> fetches via `fetch.parallel` is untested... I am willing to leave it like
> that until the time a regression is found in that code (if ever).

I believe that anything that is multi-threaded is untested in this build
target as to avoid issues with race conditions in the gcov data.

>> Johannes Schindelin	e145d993 rebase -r: support merge strategies other than `recursive`
>> sequencer.c
>> e145d993 3304) (!opts->strategy || !strcmp(opts->strategy, "recursive")) ?
> 
> I am a bit puzzled by this because the added test case in t3430 should
> cover precisely this line.

It could be that we hit "!opts->strategy" and short-circuit the strcmp, which
would mark the line as uncovered.

>> Johannes Schindelin	e2683d51 Fix .git/ discovery at the root of UNC shares
>> setup.c
>> e2683d51 952)     !is_dir_sep(dir->buf[min_offset - 1])) {
>> e2683d51 953) strbuf_addch(dir, '/');
>> e2683d51 954) min_offset++;
> 
> I think this is only tested on Windows.
> 
>> Johannes Schindelin	be5d88e1 test-tool run-command: learn to run (parts of) the testsuite
>> t/helper/test-run-command.c
>> be5d88e1 66) static int next_test(struct child_process *cp, struct strbuf *err, void *cb,
>> be5d88e1 69) struct testsuite *suite = cb;
>> be5d88e1 71) if (suite->next >= suite->tests.nr)
>> be5d88e1 72) return 0;
>> be5d88e1 74) test = suite->tests.items[suite->next++].string;
>> be5d88e1 75) argv_array_pushl(&cp->args, "sh", test, NULL);
>> be5d88e1 76) if (suite->quiet)
>> be5d88e1 77) argv_array_push(&cp->args, "--quiet");
>> be5d88e1 78) if (suite->immediate)
>> be5d88e1 79) argv_array_push(&cp->args, "-i");
>> be5d88e1 80) if (suite->verbose)
>> be5d88e1 81) argv_array_push(&cp->args, "-v");
>> be5d88e1 82) if (suite->verbose_log)
>> be5d88e1 83) argv_array_push(&cp->args, "-V");
>> be5d88e1 84) if (suite->trace)
>> be5d88e1 85) argv_array_push(&cp->args, "-x");
>> be5d88e1 86) if (suite->write_junit_xml)
>> be5d88e1 87) argv_array_push(&cp->args, "--write-junit-xml");
>> be5d88e1 89) strbuf_addf(err, "Output of '%s':\n", test);
>> be5d88e1 90) *task_cb = (void *)test;
>> be5d88e1 92) return 1;
>> be5d88e1 95) static int test_finished(int result, struct strbuf *err, void *cb,
>> be5d88e1 98) struct testsuite *suite = cb;
>> be5d88e1 99) const char *name = (const char *)task_cb;
>> be5d88e1 101) if (result)
>> be5d88e1 102) string_list_append(&suite->failed, name);
>> be5d88e1 104) strbuf_addf(err, "%s: '%s'\n", result ? "FAIL" : "SUCCESS", name);
>> be5d88e1 106) return 0;
>> be5d88e1 109) static int test_failed(struct strbuf *out, void *cb, void *task_cb)
>> be5d88e1 111) struct testsuite *suite = cb;
>> be5d88e1 112) const char *name = (const char *)task_cb;
>> be5d88e1 114) string_list_append(&suite->failed, name);
>> be5d88e1 115) strbuf_addf(out, "FAILED TO START: '%s'\n", name);
>> be5d88e1 117) return 0;
>> be5d88e1 125) static int testsuite(int argc, const char **argv)
>> be5d88e1 127) struct testsuite suite = TESTSUITE_INIT;
>> be5d88e1 128) int max_jobs = 1, i, ret;
>> be5d88e1 131) struct option options[] = {
>> be5d88e1 145) memset(&suite, 0, sizeof(suite));
>> be5d88e1 146) suite.tests.strdup_strings = suite.failed.strdup_strings = 1;
>> be5d88e1 148) argc = parse_options(argc, argv, NULL, options,
>> be5d88e1 151) if (max_jobs <= 0)
>> be5d88e1 152) max_jobs = online_cpus();
>> be5d88e1 154) dir = opendir(".");
>> be5d88e1 155) if (!dir)
>> be5d88e1 157) while ((d = readdir(dir))) {
>> be5d88e1 158) const char *p = d->d_name;
>> be5d88e1 160) if (*p != 't' || !isdigit(p[1]) || !isdigit(p[2]) ||
>> be5d88e1 161)     !isdigit(p[3]) || !isdigit(p[4]) || p[5] != '-' ||
>> be5d88e1 162)     !ends_with(p, ".sh"))
>> be5d88e1 163) continue;
>> be5d88e1 166) if (!argc) {
>> be5d88e1 167) string_list_append(&suite.tests, p);
>> be5d88e1 168) continue;
>> be5d88e1 171) for (i = 0; i < argc; i++)
>> be5d88e1 172) if (!wildmatch(argv[i], p, 0)) {
>> be5d88e1 173) string_list_append(&suite.tests, p);
>> be5d88e1 174) break;
>> be5d88e1 177) closedir(dir);
>> be5d88e1 179) if (!suite.tests.nr)
>> be5d88e1 181) if (max_jobs > suite.tests.nr)
>> be5d88e1 182) max_jobs = suite.tests.nr;
>> be5d88e1 184) fprintf(stderr, "Running %d tests (%d at a time)\n",
>> be5d88e1 187) ret = run_processes_parallel(max_jobs, next_test, test_failed,
>> be5d88e1 190) if (suite.failed.nr > 0) {
>> be5d88e1 191) ret = 1;
>> be5d88e1 192) fprintf(stderr, "%d tests failed:\n\n", suite.failed.nr);
>> be5d88e1 193) for (i = 0; i < suite.failed.nr; i++)
>> be5d88e1 194) fprintf(stderr, "\t%s\n", suite.failed.items[i].string);
>> be5d88e1 197) string_list_clear(&suite.tests, 0);
>> be5d88e1 198) string_list_clear(&suite.failed, 0);
>> be5d88e1 200) return !!ret;
>> be5d88e1 209) exit(testsuite(argc - 1, argv + 1));
> 
> This is exercised extensively in the Visual Studio job of our Azure
> Pipeline.
> 
> Thanks,
> DschO

Thank you!
-Stolee

  reply	other threads:[~2019-11-27 14:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 15:33 Git Test Coverage Report (Nov 25) Derrick Stolee
2019-11-26 20:46 ` Johannes Schindelin
2019-11-27 14:33   ` Derrick Stolee [this message]
2019-11-27 19:32     ` Johannes Schindelin
2019-11-28 22:04       ` Derrick Stolee
2019-11-28 11:06   ` Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59ae5223-6dd8-00cd-4c39-b307f8364457@gmail.com \
    --to=stolee@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).