From: Stefan Beller <sbeller@google.com>
To: Daniel Ferreira <bnmvco@gmail.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Duy Nguyen <pclouds@gmail.com>,
Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH v7 1/5] dir_iterator: add tests for dir_iterator API
Date: Mon, 3 Apr 2017 15:31:37 -0700 [thread overview]
Message-ID: <CAGZ79ka032GPTp1Y5GH5joKm1_arf4GAywPXipt869MobRwrVA@mail.gmail.com> (raw)
In-Reply-To: <1491163388-41255-2-git-send-email-bnmvco@gmail.com>
On Sun, Apr 2, 2017 at 1:03 PM, Daniel Ferreira <bnmvco@gmail.com> wrote:
> Create t/helper/test-dir-iterator.c, which prints relevant information
> about a directory tree iterated over with dir_iterator.
>
> Create t/t0065-dir-iterator.sh, which tests that dir_iterator does
> iterate through a whole directory tree.
>
> Signed-off-by: Daniel Ferreira <bnmvco@gmail.com>
> ---
> Makefile | 1 +
> t/helper/.gitignore | 1 +
> t/helper/test-dir-iterator.c | 28 +++++++++++++++++++++++
> t/t0065-dir-iterator.sh | 54 ++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 84 insertions(+)
> create mode 100644 t/helper/test-dir-iterator.c
> create mode 100755 t/t0065-dir-iterator.sh
>
> diff --git a/Makefile b/Makefile
> index 9b36068..41ce9ab 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -614,6 +614,7 @@ TEST_PROGRAMS_NEED_X += test-ctype
> TEST_PROGRAMS_NEED_X += test-config
> TEST_PROGRAMS_NEED_X += test-date
> TEST_PROGRAMS_NEED_X += test-delta
> +TEST_PROGRAMS_NEED_X += test-dir-iterator
> TEST_PROGRAMS_NEED_X += test-dump-cache-tree
> TEST_PROGRAMS_NEED_X += test-dump-split-index
> TEST_PROGRAMS_NEED_X += test-dump-untracked-cache
> diff --git a/t/helper/.gitignore b/t/helper/.gitignore
> index 758ed2e..a7d74d3 100644
> --- a/t/helper/.gitignore
> +++ b/t/helper/.gitignore
> @@ -3,6 +3,7 @@
> /test-config
> /test-date
> /test-delta
> +/test-dir-iterator
> /test-dump-cache-tree
> /test-dump-split-index
> /test-dump-untracked-cache
> diff --git a/t/helper/test-dir-iterator.c b/t/helper/test-dir-iterator.c
> new file mode 100644
> index 0000000..06f03fc
> --- /dev/null
> +++ b/t/helper/test-dir-iterator.c
> @@ -0,0 +1,28 @@
> +#include "git-compat-util.h"
> +#include "strbuf.h"
> +#include "iterator.h"
> +#include "dir-iterator.h"
> +
> +int cmd_main(int argc, const char **argv) {
> + struct strbuf path = STRBUF_INIT;
> + struct dir_iterator *diter;
> +
> + if (argc < 2) {
Coding style: please use no braces for single statements after
control structures (if, for, while).
Instead of just returning 1 (which is harder to diagnose in an
interactive shell for users who do not know the details of this
program), we could
die("BUG: test-dir-iterator takes exactly one argument");
> + return 1;
> + }
> +
> + strbuf_add(&path, argv[1], strlen(argv[1]));
> +
> + diter = dir_iterator_begin(path.buf);
> +
> + while (dir_iterator_advance(diter) == ITER_OK) {
> + if (S_ISDIR(diter->st.st_mode))
> + printf("[d] ");
> + else
> + printf("[f] ");
In the operating system there are more 'st_mode's than
just directory or file, e.g. symbolic link.
Maybe
else if (S_ISREG(diter->st.st_mode))
printf("[f] ");
else
printf("[?]");
to catch the unknown things better instead of
defaulting them to regular files?
> +#!/bin/sh
> +
> +test_description='Test directory iteration.'
> +
> +. ./test-lib.sh
> +
> +cat >expect-sorted-output <<-\EOF &&
> +[d] (a) ./dir/a
> +[d] (a/b) ./dir/a/b
> +[d] (a/b/c) ./dir/a/b/c
> +[d] (d) ./dir/d
> +[d] (d/e) ./dir/d/e
> +[d] (d/e/d) ./dir/d/e/d
> +[f] (a/b/c/d) ./dir/a/b/c/d
> +[f] (a/e) ./dir/a/e
> +[f] (b) ./dir/b
> +[f] (c) ./dir/c
> +[f] (d/e/d/a) ./dir/d/e/d/a
> +EOF
> +
> +test_expect_success 'dir-iterator should iterate through all files' '
> + mkdir -p dir &&
> + mkdir -p dir/a/b/c/ &&
> + >dir/b &&
> + >dir/c &&
> + mkdir -p dir/d/e/d/ &&
> + >dir/a/b/c/d &&
> + >dir/a/e &&
> + >dir/d/e/d/a &&
> +
> + test-dir-iterator ./dir | sort >./actual-pre-order-sorted-output &&
We just had some micro projects that were trying to get rid of git
commands on the upstream of a pipe, to better observe
the exit codes of the programs that we write here. I think it is
not as critical for test helpers, but the it would be better to diagnose
an error when we had
test-dir-iterator ./dir >out &&
sort <out >actual &&
test_cmp expect actual
as in case of an error we'd stop early in the && chain at test-dir-iterator
(and if that would use the die() function we'd even get some error message
on stderr).
> + rm -rf dir &&
I'd put that cleanup first via
test_expect_success 'title' '
test_when_finished "rm -rf dir" &&
mkdir ... &&
...
'
By doing so, an inspection is easier afterwards.
When this test breaks, you'd want to debug it via e.g.
cd t
./t0065-dir-iterator.sh -d -i -v -x # see README for all the nice flags)
which in case of error would stop at e.g. test_cmp failing. But at that
point of the test we already removed the files so it is impossible to inspect
what was on the file system, without adding a test_pause before the rm.
> +
> + test_cmp expect-sorted-output actual-pre-order-sorted-output
Usually the file names are shorter (expect, actual), but I do not
mind encoding some expectation in them.
Thanks,
Stefan
next prev parent reply other threads:[~2017-04-03 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-02 20:03 [PATCH v7 0/5] [GSoC] remove_subtree(): reimplement using iterators Daniel Ferreira
2017-04-02 20:03 ` [PATCH v7 1/5] dir_iterator: add tests for dir_iterator API Daniel Ferreira
2017-04-03 22:31 ` Stefan Beller [this message]
2017-04-02 20:03 ` [PATCH v7 2/5] remove_subtree(): test removing nested directories Daniel Ferreira
2017-04-03 22:35 ` Stefan Beller
2017-04-02 20:03 ` [PATCH v7 3/5] dir_iterator: add helpers to dir_iterator_advance Daniel Ferreira
2017-04-03 22:48 ` Stefan Beller
2017-04-02 20:03 ` [PATCH v7 4/5] dir_iterator: refactor state machine model Daniel Ferreira
2017-04-03 3:36 ` Michael Haggerty
2017-04-03 18:03 ` Daniel Ferreira (theiostream)
2017-04-04 6:36 ` Michael Haggerty
2017-04-02 20:03 ` [PATCH v7 5/5] remove_subtree(): reimplement using iterators Daniel Ferreira
2017-04-03 3:42 ` Michael Haggerty
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=CAGZ79ka032GPTp1Y5GH5joKm1_arf4GAywPXipt869MobRwrVA@mail.gmail.com \
--to=sbeller@google.com \
--cc=bnmvco@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.com \
/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).