[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[hyades-dev] trace, record, format, was: Junit-based tools integration Document Update
- From: Thomas L Roche <tlroche@xxxxxxxxxx>
- Date: Fri, 5 Nov 2004 13:51:00 -0500
- Delivered-to: firstname.lastname@example.org
As a native speaker of English, a (hopefully) competent speaker of
JUnit and development, and a TPTP novice, I have some questions (and
Michael Norman 03/11/2004 22:27:21:
>> On the recorder thing, is there aything to stop us from having an
>> external trace model, analogous to an external behaviour.
What's the difference between "trace" and "behavior"? Is a trace just
a record of a behavior? (Here I'm using the familiar (to me) developer
sense of "trace statements," e.g. writing diagnostic text to stderr to
indicate in realtime the current locus of execution.) Or is it the
record of a test (i.e. what failed)?
In the JUnit world, you have code which both creates/exercises your
SUT and tests its state, but nothing which records the tests/
assertions which failed (or succeeded, for that matter). Costello
gives one a way to record the behavior (to xml), and then to play it
back (i.e. recreate the behavior by converting xml to code
on-the-fly), but it does not record what failed/succeeded.
Julien Canches Fri, 5 Nov 2004 16:18:55 +0100
> There are existing recording tools around that already have their
> own recording format. This is the case for instance for Costello
> (UI-testing, Abbot script editor), but also for our own tools (URL
> tests are generated from a .rec file). If we want to allow these
> tools to integrate into Hyades without requiring them to rewrite
> everything, we need to support the use of proprietary recording
Just to avoid introducing other issues (e.g. openness, copyright,
licensing), consider s/proprietary/external. In the case of Costello,
the format is open (CPL) and human-readable (XML), not proprietary.
But it is certainly external to Hyades.
> As far as wording is concerned, I agree that "external trace model"
> is a good alternative to "proprietary recording format".
So if "trace model"=="recording format" that would seem to imply that
trace == record of behavior.
> These tools have the option later to migrate their own model to the
> trace model, but requiring them to change to the trace model as a
> ticket for entering Hyades is likely to be discouraging.
>> Isn't it confusing to have a trace (ie recording) in the context of
>> a test, which is allowed to be external, whereas a trace for other
>> purposes isn't?
> Maybe the confusion appears by saying trace *ie* recording. Why not
> keeping the two notions separate ? A recording is something used for
> generating a test, whereas a trace has a more generic meaning. And a
> trace *may* be a recording.
So IIUC a recording is a trace that can be played back? And the "more
generic meaning" of trace is "a record of the behavior of a SUT"?
Please point me toward a glossary, if one exists.