Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Ramsay Jones wrote:
>>> Junio C Hamano wrote:
>>
Observing that all well-written test scripts we have begin with this
boilerplate line:
test_expect_success setup '
I wouldn't mind introducing a new helper function
Jonathan Nieder writes:
> Ramsay Jones wrote:
>> Junio C Hamano wrote:
>
>>> Observing that all well-written test scripts we have begin with this
>>> boilerplate line:
>>>
>>> test_expect_success setup '
>>>
>>> I wouldn't mind introducing a new helper function test_setup that
>>> behaves lik
Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> FWIW I find Junio's test_setup name more self-explanatory. What
>> mnemonic should I be using to remember the _fixture name?
>
> Previous exposure to things like Rails?
I did once have a brief look at ruby, but my "new language to learn"
lis
Jonathan Nieder wrote:
> [...]
>> [1] For example, what should/will happen if someone uses test_must_fail,
>> test_might_fail, etc., within the test_fixture script? Should they simply
>> be banned within a text_fixture?
>
> Why wouldn't they act just like they do in test_expect_success blocks?
He
Jonathan Nieder writes:
> FWIW I find Junio's test_setup name more self-explanatory. What
> mnemonic should I be using to remember the _fixture name?
Previous exposure to things like Rails?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v
Hi,
Ramsay Jones wrote:
> Junio C Hamano wrote:
>> Observing that all well-written test scripts we have begin with this
>> boilerplate line:
>>
>> test_expect_success setup '
>>
>> I wouldn't mind introducing a new helper function test_setup that
>> behaves like test_expect_success but is me
Junio C Hamano wrote:
[...]
> As I am more worried about longer-term health of the codebase, what
> the part you moved outside test_expect_* with this patch happens to
> do _right now_ is of secondary importance, at least from my point of
> view. The next patch that updates this scirpt may want to
Jonathan Nieder wrote:
> [...]
>> No, I don't think this would be a good direction to go in. This may
>> not be a good idea either, but if you wanted to add a check here, then
>> maybe something like this (totally untested):
>>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index acda33d..53a2422
Ramsay Jones writes:
> The only problematic platforms I test on are "NTFS/bash" on cygwin and MinGW.
> Since commit 2b843732 ("Suppress some bash redirection error messages",
> 26-08-2008), I have not noticed any complaints regarding this problem.
> What have I missed?
>
> Assuming we are not tal
Hi,
Ramsay Jones wrote:
> The only problematic platforms I test on are "NTFS/bash" on cygwin and MinGW.
> Since commit 2b843732 ("Suppress some bash redirection error messages",
> 26-08-2008), I have not noticed any complaints regarding this problem.
Yeah, that probably took care of squashing th
Jonathan Nieder wrote:
>> Needless to say, I much prefer the patch below. :-D
>
> Thanks for a nice explanation. In general I definitely like getting
> rid of these setup tests when possible. Let's see:
>
> [...]
>> --- a/t/t3300-funny-names.sh
>> +++ b/t/t3300-funny-names.sh
>> @@ -15,28 +15,2
(cc-ing Ævar, TAP wizard)
Hi,
Ramsay Jones wrote:
> $ ./t3300-funny-names.sh
> ok 1 - setup
> # passed all 1 test(s)
> 1..1 # SKIP Your filesystem does not allow tabs in filenames
> $
>
> Unfortunately, this is not valid TAP output, which prove notes
> as follows:
[...]
>
At present, running the t3300-*.sh test on cygwin looks like:
$ cd t
$ ./t3300-funny-names.sh
ok 1 - setup
# passed all 1 test(s)
1..1 # SKIP Your filesystem does not allow tabs in filenames
$
Unfortunately, this is not valid TAP output, which prove notes
as follows:
13 matches
Mail list logo
