Re: [PATCH 03/10] t4018: an infrastructure to test hunk headers

[Johannes Sixt <j6t@kdbg.org>]

Am 21.03.2014 23:00, schrieb Junio C Hamano:
> Johannes Sixt <j6t@kdbg.org> writes:
> 
>> Add an infrastructure that simplifies adding new tests of the hunk
>> header regular expressions.
>>
>> To add new tests, a file with the syntax to test can be dropped in the
>> directory t4018. The README file explains how a test file must contain;
> 
> s/how/what/, or "how a test file must be written" you mean?

I do mean one of those, preferably the latter ;)

>> -for p in ada bibtex cpp csharp fortran html java matlab objc pascal perl php python ruby tex
>> +diffpatterns="
>> +	ada
>> +	bibtex
>> +	cpp
>> +	csharp
>> +	fortran
>> +	html
>> +	java
>> +	matlab
>> +	objc
>> +	pascal
>> +	perl
>> +	php
>> +	python
>> +	ruby
>> +	tex
>> +"
>> +
>> +for p in $diffpatterns
>>  do
>>  	test_expect_success "builtin $p pattern compiles" '
>>  		echo "*.java diff=$p" >.gitattributes &&
> 
> I always found this "Let's apply rules for language $p to these
> *.java files" strange.  I have wonder if it makes sense to further
> change the framework to read the name of the rule to be applied from
> the file in t/t4018/ directory, instead of using filename that is
> the same as the name of the rule?  That way, you can list the files
> in t/t4018/ directory to come up with the above list, without having
> to maintain the list of rules separately like the above.

I see what you mean. Notice, however, that we also test whether the
regular expressions can be compiled successfully, and for this it is
desirable to have the complete list of userdiff drivers. Until we have
at least one test-case for each driver, we wouldn't get the complete
list. In summary, I do agree that a bit more automation is also
desirable, but we are not there, yet.

-- Hannes