New testsuite based on Git's test-lib.sh #220
Conversation
The Perl scripts were only running shell commands anyway; this seemed a more natural fit. Since bash does not capture trailing newlines, there is a change to the "vcsh status" check from 300-add.t to ensure the empty line is/isn't printed according to the terseness setting.
What do you know, Git does this for us.
Let us hope there are no spaces in the user's path, because this will allows us to set VCSH="bash vcsh", VCSH="dash vcsh", etc.
This will simplify use with a harness like prove.
Still works with bats.
|
@RichiH Still have interest in this? The current 165 tests are mergeable/usable/passing as-is (with 17 marked as expect_failure for existing issues). |
The state each test should return to is having the vcsh repos are in sync with their upstreams. With these as test_setup, it actually makes things more different when skipping/selecting tests.
Rather than check to see if core.excludesfile and core.attributesfile are set, check to see if the data written to the agreed-upon ignore or attributes file actually takes effect. (Less reliance on internals.)
Redirections with >&, piping with |&, and brace expansion weren't handled by dash. Replace with portable equivalents.
These check to make sure that values from the environment don't interfere with internal variables used by vcsh.
No need for this with test-lib.sh
This suite can be fleshed out with some clarification on how exactly config files are supposed to work/be used.
|
I'm a bit late to the party here so excuse my confusion, but can I ask what the motivation for this is? I could see wishing to move away from Perl, but why would some mataure test framework like @djpohly Are you still interested in this? I don't want work to go to waste but I also want something that's actually going to be a long term benefit and at first blush I'm unclear on what the gain is. |
|
There's no migrating to or away from Bats here; either testsuite is better than what vcsh currently has, which is essentially none. You'll notice I wrote both - I was simply trying a couple of options for more thorough testing to see if one worked better than the other, and I happened to try Bats first. In terms of long-term benefit, however, I found it much easier to write solid tests with Git's test-lib.sh harness. Bats is pretty limited in what it does, and test-lib.sh is more feature-rich and mature, having been actively developed since Git 1.0 (2005). Convenience functions for working with Git repositories, like I'm sure that some of the relevant conveniences could be copied from test-lib.sh to a Bats library if that's what the devs want. Or they can throw it all out. Personally, it doesn't matter to me - I wrote tests so that I could potentially start working on refactoring vcsh, but since nothing was merged I moved on to other things. |
|
Thanks @djpohly that's helpful background for reviewing this. |
Closes #218
I've taken the tests that were written using Bats and ported them to Git's testing harness. Advantages:
I'll keep tinkering and expanding but wanted to let you know this was ready and available.