[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Perl and Emacs: Developing tests for progmodes
From: |
Harald Jörg |
Subject: |
Re: Perl and Emacs: Developing tests for progmodes |
Date: |
Thu, 3 Sep 2020 22:00:22 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
On 9/3/20 7:34 PM, Eli Zaretskii wrote:
>> From: Harald Jörg <haj@posteo.de>
>> Date: Thu, 3 Sep 2020 15:42:47 +0200
>> Cc: Stefan Kangas <stefankangas@gmail.com>,
>> Stefan Monnier <monnier@iro.umontreal.ca>
>>
>> To solve this, we could:
>>
>> - Split the tests into two and manually copy over tests where this
>> makes sense or:
>>
>> - Split the tests into a "common" set plus two sets for the specific
>> modes (how would the files be named in that case?) or:
>>
>> - Keep all tests in one file and tag the individual tests.
>>
>> Are there any similar cases in the set of Emacs packages, or
>> conventions how to do it?
>
> Don't perl-mode and cperl-mode live on 2 separate files?
They do.
> We generally
> have a structure under test/ that mirrors the file hierarchy of the
> sources being tested, so it would be natural to have 2 separate files,
> test/lisp/progmodes/perl-mode-tests.el and
> test/lisp/progmodes/cperl-mode-tests.el.
Such was my understanding of test/file-organization.org, too.
> Does that answer your question?
Not really: As far as I understand, Stefan Monnier augmented the first
version of cperl-mode-tests.el so that it is also applicable for
perl-mode.el (commit 7a7847d7ad5). So, a (not-yet-existing)
perl-mode-tests.el would just (let ((cperl-test-mode #'perl-mode)) and
then run the tests in cperl-mode-tests.pl.
For that to work, the tests in cperl-mode-tests.el need to co-operate.
My recent test written for (Bug#16368) calls a function which is only
available in cperl-mode, and the tests for (Bug#10483) exercise
cperl-mode's indentation by calling `cperl-indent-exp' and expect
cperl-mode's indentation results. The simple approach from above
would then either give false negative results (whenever perl-mode runs
against cperl-mode's expectations) or just run the same test twice
(when the test explicitly calls a cperl-mode function).
Adding a line (skip-unless (eq cperl-test-mode #'cperl-mode)), as
suggested by Stefan Monnier, will do the trick, and will allow me to
continue chasing old bugs or even add new bugs, eerm, features.
--
Cheers,
haj