From: Stefan Kangas <stefankangas@gmail.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gnu.org
Subject: Re: Tests and linting not coupled to one file
Date: Fri, 25 Sep 2020 15:36:31 +0000 [thread overview]
Message-ID: <CADwFkmnp+Uo4b8RwDg3VcwHnyLCSoz008hgRWCPwRtZT1FDjSw@mail.gmail.com> (raw)
In-Reply-To: <87y2kynf4n.fsf@gnus.org>
Lars Ingebrigtsen <larsi@gnus.org> writes:
>> One idea I've had is to create a new directory "test/misc" or something
>> to keep such tests in. We could arrange for them to be run with
>> "check-expensive" and continue using ert to get standardized reporting,
>> etc.
>>
>> The custom tests are good candidates here, but there are others.
>
> I think that makes sense, but I wonder whether there's much to be gained
> by doing that. If somebody is looking for "what's that test that checks
> all the defcustom declaration", would they look in lisp/custom-tests.el
> or misc/defcustom-tests.el?
That's a fair point. Likely they would not be aware of "test/misc" at
first. OTOH we could document it in "test/file-organization.org".
Here's three scenarios where adding a test to the existing files might
not make sense:
- Running `admin/check-doc-strings' automatically.
- Automatic linting using third-party tools. We don't do that today
AFAIK, but it might be worth investigating. I found a relatively long
list of typos recently using "codespell", and "shellcheck" may or may
not make sense to use for our shell-scripts. Just to give two
examples of reasonably realistic candidates.
- I have a half-baked shell script with some simple heuristics that I've
used to find like 100 misspelled symbols in doc strings and comments.
Maybe we would want to run something like it automatically in the
future.
(I will push a fix for the typos I found to emacs-27 when I find some
time.)
That said, if we can find a way to shoe-horn the stuff we need into the
existing test suite without it being overly ugly, it's perfectly fine by
me. Perhaps that would be less ugly than adding a new "test/misc"
directory.
next prev parent reply other threads:[~2020-09-25 15:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200925124646.29315.84502@vcs0.savannah.gnu.org>
[not found] ` <20200925124647.83150209D4@vcs0.savannah.gnu.org>
2020-09-25 13:11 ` Tests and linting not coupled to one file (was: Re: master 664927b: Add an expensive test for defcustom types) Stefan Kangas
2020-09-25 13:46 ` Tests and linting not coupled to one file Lars Ingebrigtsen
2020-09-25 15:36 ` Stefan Kangas [this message]
2020-09-26 13:38 ` Lars Ingebrigtsen
2021-02-21 10:37 ` Stefan Kangas
2021-02-21 13:18 ` Lars Ingebrigtsen
2021-02-21 19:34 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADwFkmnp+Uo4b8RwDg3VcwHnyLCSoz008hgRWCPwRtZT1FDjSw@mail.gmail.com \
--to=stefankangas@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).