Add tests

[felipec]

It would be useful to have some kind of tests, I personally like Sharness (which I recently inherited).

It uses shell scripts and tests are really simple:

test_expect_success 'foo' '
  hg init
'

In this proposal I've added just two tests, but the merge one is already useful to detect issues in some changes I'm working on.

This is what I use in git-remote-hg which has quite extensive tests (e.g. main.t), also what I'm using in my new project hg-fast-export (e.g. main.t), and this is what the Git project uses (e.g. t0001-init.sh).

It's pretty easy to setup, one can just clone the repository to t/sharness, or we can include the whole script which is around 760 lines of code.

It's also easy to setup GitHub actions to run these tests, as you can see I'm setting up an action in this pull request, and the results of one job are here.

It would be nice to have at least some tests, and even nicer if we could share them between projects.

[frej]

This looks very appealing, I like the idea of more testing. I have been using a (not published) smoke test to check for breaking changes. I'll take a stab at converting it to Sharness. If that works out, I'll merge this one (and then #299 to verify that it doesn't change the result).

It's pretty easy to setup, one can just clone the repository to t/sharness, or we can include the whole script which is around 760 lines of code.

I'd prefer to add it as a submodule, that way there is never a question about which version of the framework which is supposed to be used and it is fairly easy to see if there are upstream changes.

It would be nice to have at least some tests, and even nicer if we could share them between projects.

I agree. If the common tests were in their own repo we could just include them as a submodule.

[felipec]

I'd prefer to add it as a submodule, that way there is never a question about which version of the framework which is supposed to be used and it is fairly easy to see if there are upstream changes.

I'm not a fan of submodules, but that's possible.

I agree. If the common tests were in their own repo we could just include them as a submodule.

That's also a possibility. I've been running some tests interchangeably with your hg-fast-export, my hg-fast-export, and Mercurials official hg fastexport.

[felipec]

Any specific reason not to use make to run the tests?

I checked your run-tests script which basically just executes the test files in t/ and if parallel is found, use it.

But the same can be dune by using make (if you have MAKEFLAGS=-j). I copied the example Makefile in sharness' example/Makefile, and it works fine.

BTW. It's a good idea to remove the sharness cruft before and after the tests. See the Makefile.

[felipec]

Also, what is this about?

if ! $READLINK -f "$(which "$0")" > /dev/null 2>&1 ; then
    ROOT="$(dirname "$(which "$0")")"
else
    ROOT="$(dirname "$($READLINK -f "$(which "$0")")")"
fi

I suppose you want the absolute path of the real location of the project, but you can do that in a portable way with: $(cd "$(dirname "$0")" && pwd -P).

[frej]

$(cd "$(dirname "$0")" && pwd -P) is nicer than the old stuff we've been using in hg-fast-export.sh to locate the python files.

And using make is a nicer way too.