Gazebo Hub Common Lisp (GHCL) Work Area - Summary of Current Work

Ed. Note: See also, Project Lupine

I've begun developing the Common Lisp work area in the Gazebo Hub project. The first item added is the Gazebo Hub fork of cl-xml (with more to follow about that, soon, I hope). Today, I've started working on a set of ASDF extensions that I'd started putting together a design about, some few days ago, for release tooling, firstly in porting some procedures that it seems upstream CL-XML may be using, in its own release tooling (to be documented in more detail) then secondly, in extending on that pattern, for purpose of automating some matters of documentation generation (w.r.t DocBook), file archiving (w.r.t Salza2 and Archive) and file publishing (w.r.t SourceForge and GitHub services for managing file releases, and such that would design to offer support for Common-Lisp.net projects, also)

As of this morning, all I've got put together, in code, is a set of classes and operations for purpose of implementing a recursive copy-sources-op onto ASDF, with output file translations and some bells and whistles on the I/O side. I've yet to put together a Git repository, here at the GH SF.net web resources, to host that with - would rather unit test it, first, then publish it to a public Git repository.

As far as unit testing, that's what I wanted to focus on, with this 'blog entry. I thought it would be appropriate to offer that brief summary, as in the previous, about the rest of the work in the Gazebo Hub Common Lisp work area, at this time, however.

This afternoon, I've wanted to take a look at some available options for automation of unit testing, in such as may integrate easily with ASDF. I'm looking at NST, at this time, specifically. I've also taken a look at FiveAM. I'm interested in looking at a system that may already provide some integration with ASDF.

Reading NST's documentation, I see that NST defines a couple of component classes for integrating NST with ASDF. I think that's great. At least in writing, then, I'd like to address the question of whether it may be possible, by at least one methodology, to run unit tests on ASDF systems without requiring that the ASDF systems themselves would use classes from the unit testing harness - namely, so that a ASDF systems' system definition would not necessarily need to load the unit testing framework, in order to successfully load the system definition, for purposes not involving unit testing. I think it may serve to keep the system definition dependencies "lighter" at that. Of course, though, it would need more than a bar napkin note, to make it work....

So, but here's my digital bar napkin note. The following will probably sound however it may sound - circularly speaking, at that, with an apology for if there may be too much novelty about it.

What I would like for a unit testing harness to do, when running a unit test on an ASDF system, I think it would be just about so:
1. Load the system definition
2. Load the test definitions
3. Run the tests defined in the test definitions

I would like to be able to load the system definition, without having to load the test harness, at that time. I think, the test harness should be needed in order to load and run the test definitions, not earlier. I would like to keep the test harness "in that lane," so to speak - for loading and running the unit tests.

As far as how to associate a set of test definitions with any primary source code - namely, forms for which the test definitions would serve in makings unit tests - there may be any number of approaches suggested. I would like to focus developing on one possible approach, to start with - such that may integrate with ASDF, as well.

I think it could be as simple as this:
1) Load component "foo" (cl-source-file) from file foo.lisp
2) Load "foo-test.lisp" to load the unit tests for "foo"
2.A) There may be an "effective component" interpreted onto "foo", namely "foo-test" - such that maybe derived from "foo" when the system is operated on for unit testing, or may be somehow defined explicitly (perhaps, via properties onto "foo" itself), as in order to be able to denote test dependencies in a manner extending the set of dependencies of component "foo", and for recording any other system qualities that may be necessary specifically for the unit testing
3) Run the tests defined in "foo-test. If those tests are contained in one or more test suites, those could be denoted in the component definition of "foo" itself, using properties extending on the basic ASDF model - the system not per se requiring that "foo" be defined with a special component class, to facilitate the unit testing, if all the keyword properties that would be needed for unit testing "foo" can be defined to "foo" as a component, without special test-specific class extensions or the system definition dependencies that those would introduce.
4) ...recording the output from the unit tests, somewhere. I noticed that NST supports, to some extent, an XML report format used with JUnit. I think that's grand - that feature could be useful in generating web content for a project, or even for some kind of tinderbox framework.
5) Then, (as a developer) evaluate the results of the tests. If necessary, correct and/or extend the source code, further, lastly stage the item for release, then package and release the item.
6) "Sometime later, a release party!" so to speak.

Skipping the matter of hats and kazoos, for now, I think it must certainly be possible to use NST for that kind of a unit testing framework. It's for that that I propose to develop an extension on NST, for using ASDF without per se requiring that NST be loaded before the system definition is loaded.

I should come up with a novel name for it, perhaps, to identify the matter succinctly. It would be developed in the GH-CL-REL-TOOL work area.

"Then again," candidly, I've yet to define so much as the test cases for the source code I'd written, this morning. At least I've got a bar napkin about this tangent, now, - something I could review, later, after defining those unit tests. It looks like I'll use NST for that!