From 0c319e63eb4054268604048d0b07c81b97a1b5ee Mon Sep 17 00:00:00 2001 From: "Robert P. Goldman" <rpgoldman@gmail.com> Date: Sun, 6 Apr 2014 12:07:24 -0500 Subject: [PATCH] Cut down the TEST-OP discussion in FAQ. It's now redundant with the definition of the TEST-OP built-in operation class. I don't want to have to maintain two separate discussions of the same material. --- doc/asdf.texinfo | 75 ++++++++++++++++++++++++------------------------ 1 file changed, 38 insertions(+), 37 deletions(-) diff --git a/doc/asdf.texinfo b/doc/asdf.texinfo index d0174ac1..7faad5a0 100644 --- a/doc/asdf.texinfo +++ b/doc/asdf.texinfo @@ -5017,7 +5017,6 @@ use (after loading ASDF but before using it): @node How can I cater for unit-testing in my system?, How can I cater for documentation generation in my system?, Issues with using and extending ASDF to define systems, Issues with using and extending ASDF to define systems @subsection ``How can I cater for unit-testing in my system?'' -@c FIXME: cross-reference the TEST-OP section. ASDF provides a predefined test operation, @code{test-op}. @xref{Predefined operations of ASDF, test-op}. @@ -5027,48 +5026,50 @@ a topic of considerable discussion on the @url{http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel,asdf-devel mailing list}, and on the @url{https://launchpad.net/asdf,launchpad bug-tracker}. +We provide some guidelines in the discussion of @code{test-op}. -Here are some guidelines: +@c cut the following because it's discussed in the discussion of test-op. +@c Here are some guidelines: -@itemize -@item -For a given system, @var{foo}, you will want to define a corresponding -test system, such as @var{foo-test}. The reason that you will want this -separate system is that ASDF does not out of the box supply components -that are conditionally loaded. So if you want to have source files -(with the test definitions) that will not be loaded except when testing, -they should be put elsewhere. - -@item -The @var{foo-test} system can be defined in an asd file of its own or -together with @var{foo}. An aesthetic preference against cluttering up -the filesystem with extra asd files should be balanced against the -question of whether one might want to directly load @var{foo-test}. -Typically one would not want to do this except in early stages of -debugging. +@c @itemize +@c @item +@c For a given system, @var{foo}, you will want to define a corresponding +@c test system, such as @var{foo-test}. The reason that you will want this +@c separate system is that ASDF does not out of the box supply components +@c that are conditionally loaded. So if you want to have source files +@c (with the test definitions) that will not be loaded except when testing, +@c they should be put elsewhere. -@item -Record that testing is implemented by @var{foo-test}. For example: -@example -(defsystem @var{foo} - :in-order-to ((test-op (test-op @var{foo-test}))) - ....) +@c @item +@c The @var{foo-test} system can be defined in an asd file of its own or +@c together with @var{foo}. An aesthetic preference against cluttering up +@c the filesystem with extra asd files should be balanced against the +@c question of whether one might want to directly load @var{foo-test}. +@c Typically one would not want to do this except in early stages of +@c debugging. -(defsystem @var{foo-test} - :depends-on (@var{foo} @var{my-test-library} ...) - ....) -@end example -@end itemize +@c @item +@c Record that testing is implemented by @var{foo-test}. For example: +@c @example +@c (defsystem @var{foo} +@c :in-order-to ((test-op (test-op @var{foo-test}))) +@c ....) + +@c (defsystem @var{foo-test} +@c :depends-on (@var{foo} @var{my-test-library} ...) +@c ....) +@c @end example +@c @end itemize -This procedure will allow you to support users who do not wish to -install your test framework. +@c This procedure will allow you to support users who do not wish to +@c install your test framework. -One oddity of ASDF is that @code{operate} (@pxref{Operations,operate}) -does not return a value. So in current versions of ASDF there is no -reliable programmatic means of determining whether or not a set of tests -has passed, or which tests have failed. The user must simply read the -console output. This limitation has been the subject of much -discussion. +@c One oddity of ASDF is that @code{operate} (@pxref{Operations,operate}) +@c does not return a value. So in current versions of ASDF there is no +@c reliable programmatic means of determining whether or not a set of tests +@c has passed, or which tests have failed. The user must simply read the +@c console output. This limitation has been the subject of much +@c discussion. @node How can I cater for documentation generation in my system?, How can I maintain non-Lisp (e.g. C) source files?, How can I cater for unit-testing in my system?, Issues with using and extending ASDF to define systems @subsection ``How can I cater for documentation generation in my system?'' -- GitLab