Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[tlug] Triggering Automated Test Runs



On 2018-04-19 15:30 +0900 (Thu), Stephen J. Turnbull wrote:

> That's an interesting concept, test-on-save.  How much testing does
> that trigger?

It depends on how you configure (or write) it. Most implementations
seem to split this into two parts: watching for changes (usually via
[inotify]) and triggering a test run when it sees a change. In all the
implementations I've seen it didn't matter what the change was; the
selection mechanism of what to run was completely separate.

In my `watchrun` script (which is basically just a quick hack) I tell
it what to run, so it's really just a way to avoid having to move over
from my editor window to my shell window and run the last command from
the history. I'll ask my test system to run whichever bits are
important to me and run reasonably quickly for the stuff I'm working
on, and when I need broader coverage I'll kill it and run the broader
set of tests manually.

A popular implementation of this is [Jest], where it starts out
running tests for any files that have changed since the last commit.
(These are, I believe, test files that have changed and via a simple
naming convention test files associated with code-under-test files
that have changed.) You can interactively give it filename/path
patterns to have it run different tests or just hit `a` for all tests.
This is of course unit tests only if you're doing a typical thing
where functional and integration tests (which may start several
clients and servers and have them interacting with each other) are run
by a different test framework.

[inotify]: https://en.wikipedia.org/wiki/Inotify
[Jest]: https://facebook.github.io/jest/

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links