Tup doesn't have phony targets like in make, so the 'make && make test'
where 'test' is a PHONY target doesn't have a direct analogue in tup. You
can still put tests in a Tupfile, which in general would be a rule that has
an input (the program under test), and a command (the test to run), but no
outputs. Something like this:
: foreach test*.sh | prog |> sh %f |>
This tells tup to create a command for each test file (test*.sh) which
depends on the program 'prog' ('prog' is in the order-only inputs section,
so it isn't iterated as part of the foreach loop). The test cases are run
with the bourne shell. No files are expected to be written to by these
tests (although you could add an output like a log file here if you
wanted). You can just have the test return 0 for success, or non-zero for
failure. Tup will re-run any failed tests on a future update, even if the
program itself hasn't changed.
Note that with the test cases in the Tupfile, just running 'tup' will both
build your program and run all the tests. If you have many tests, this may
not be what you want. You could still just build the program itself (by
running 'tup prog'), or you can build the program and run a single test by
specifying the command string (eg: tup 'sh test1.sh'). Note that if you do
'tup test1.sh', it will try to build only up to the test1.sh file itself,
not the command to execute it. Since this is presumably a file you manually
wrote yourself, that would do nothing.
For tup itself you can see that the tests aren't in the Tupfiles at all,
which is another option to consider. In the test directory there are just
independently executable test files, so a single test can be run with
'./t4000-compile-c.sh', with a './test.sh' that runs all tests. I do it
this way because I don't want to run tup tests inside another instance of
tup, but I also like the separation of 'tup' just doing a build and not
running a full test suite.
For other projects I usually put quick tests (think style checkers,
linters, etc) inside the Tupfile because they are unobtrusive enough to not
cause a long edit-compile-test cycle, and those sorts of errors are usually
easier to fix right in the middle of editing the code rather than later
(during check-in time, for example). For a longer-running suite of tests,
I have them separately executable so I can skip them if I want to focus on
one particular aspect of the program at a time, and then run them all
before committing.
Hope that helps,
-Mike
On Wed, Jun 7, 2023 at 10:36 PM Jesse Thompson <[email protected]> wrote:
> So I've gone through the learn/forget cycle with how to use `make` many
> times in the last few decades. I'm on the forget end of that now looking
> for a good alternative system.
>
> I'm starting a small project where I'd like to be able to build an
> optimized version of code, a debug version of code good for running `gdb`
> over, and to have a bunch of unit tests that I can also run on demand.
>
> No library dependencies yet, just blocks of code that I'm writing and
> header files that I'm writing. Avoiding even glibc like the plague as is my
> wont. Writing my own TAP producers for the tests.
>
> In `make` I can grok the general idea of phony targets and such for verbs
> not directly related to specific output files like "test", so I'm just
> wondering how to go about that sort of thing in tup .. or how tup might
> approach that problem instead.
>
> --
> --
> tup-users mailing list
> email: [email protected]
> unsubscribe: [email protected]
> options: http://groups.google.com/group/tup-users?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "tup-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tup-users/de24dec7-7175-4fed-a7e0-6e587695db27n%40googlegroups.com
> <https://groups.google.com/d/msgid/tup-users/de24dec7-7175-4fed-a7e0-6e587695db27n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tup-users/CA%2B6x0LVAh9Xb_vKqRTniAU6%2B6HeNyxfNvDKsSZxn_rj5WR_buQ%40mail.gmail.com.
