unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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.



  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).