[doc] doesn't support printing variables

[jsherman256]

I prefer the format of [doc] over the format of [progress] for printing out values that are important to test cases (especially when debugging). However, the variable is printed out as a string literal "${var}" rather than printing the content of ${var}

[hawk]

The main purpose with the doc tags are to provide a (static) overview of
what the purpose is with the various test cases. A simplified test spec.

Supporting variables in the doc tags would make the "test spec" quite ugly
as most of the variables would only be set while executing the tests. That
is they are not set when the script is preprocessed to extract the doc tags.

I think a better idea is to allow newlines and tabs in the progress tags.

/Håkan
On Oct 29, 2015 12:13 AM, "jsherman256" [email protected] wrote:

I prefer the format of [doc] over the format of [progress] for printing
out values that are important to test cases (especially when debugging).
However, the variable is printed out as a string literal "${var}" rather
than printing the content of ${var}

—
Reply to this email directly or view it on GitHub
#6.

[hawk]

An alternate approach is to use the "tail" (or "t" for short) command in
the debugger. (The debugger is normally enabled and reads commands from
stdin. Just enter a command and hit enter.) With the "tail" command it is
possible to display the contents of lux various log files. By default the
event log is displayed. This is quite useful when a test script is stuck
somewhere and you want to determine what it has done and what it is waiting
for. Hitting enter an extra time repeats the previous command. In case of
the "tail" command the first invokation prints out the last 10 lines.
Hitting enter once more prints out the last 20 etc.

/Håkan

On Thu, Oct 29, 2015 at 8:43 AM, Håkan Mattsson [email protected]
wrote:

The main purpose with the doc tags are to provide a (static) overview of
what the purpose is with the various test cases. A simplified test spec.

Supporting variables in the doc tags would make the "test spec" quite ugly
as most of the variables would only be set while executing the tests. That
is they are not set when the script is preprocessed to extract the doc tags.

I think a better idea is to allow newlines and tabs in the progress tags.

/Håkan
On Oct 29, 2015 12:13 AM, "jsherman256" [email protected] wrote:

I prefer the format of [doc] over the format of [progress] for printing
out values that are important to test cases (especially when debugging).
However, the variable is printed out as a string literal "${var}" rather
than printing the content of ${var}

—
Reply to this email directly or view it on GitHub
#6.

[hawk]

The debugger is also enabled when you use the more compact TAP printout
(enabled with "lux -t"). I our Jenkins runs we use "lux -t" to shrink the
output on stdout a bit.

/Håkan

On Fri, Oct 30, 2015 at 11:01 AM, Håkan Mattsson [email protected]
wrote:

An alternate approach is to use the "tail" (or "t" for short) command in
the debugger. (The debugger is normally enabled and reads commands from
stdin. Just enter a command and hit enter.) With the "tail" command it is
possible to display the contents of lux various log files. By default the
event log is displayed. This is quite useful when a test script is stuck
somewhere and you want to determine what it has done and what it is waiting
for. Hitting enter an extra time repeats the previous command. In case of
the "tail" command the first invokation prints out the last 10 lines.
Hitting enter once more prints out the last 20 etc.

/Håkan

On Thu, Oct 29, 2015 at 8:43 AM, Håkan Mattsson [email protected]
wrote:

The main purpose with the doc tags are to provide a (static) overview of
what the purpose is with the various test cases. A simplified test spec.

Supporting variables in the doc tags would make the "test spec" quite
ugly as most of the variables would only be set while executing the tests.
That is they are not set when the script is preprocessed to extract the doc
tags.

I think a better idea is to allow newlines and tabs in the progress tags.

/Håkan
On Oct 29, 2015 12:13 AM, "jsherman256" [email protected] wrote:

I prefer the format of [doc] over the format of [progress] for printing
out values that are important to test cases (especially when debugging).
However, the variable is printed out as a string literal "${var}" rather
than printing the content of ${var}

—
Reply to this email directly or view it on GitHub
#6.

[hawk]

Now (1.9.5) you can have newlines and tabs in the [progress] command.

/Håkan

On Fri, Oct 30, 2015 at 11:06 AM, Håkan Mattsson [email protected]
wrote:

The debugger is also enabled when you use the more compact TAP printout
(enabled with "lux -t"). I our Jenkins runs we use "lux -t" to shrink the
output on stdout a bit.

/Håkan

On Fri, Oct 30, 2015 at 11:01 AM, Håkan Mattsson [email protected]
wrote:

An alternate approach is to use the "tail" (or "t" for short) command in
the debugger. (The debugger is normally enabled and reads commands from
stdin. Just enter a command and hit enter.) With the "tail" command it is
possible to display the contents of lux various log files. By default the
event log is displayed. This is quite useful when a test script is stuck
somewhere and you want to determine what it has done and what it is waiting
for. Hitting enter an extra time repeats the previous command. In case of
the "tail" command the first invokation prints out the last 10 lines.
Hitting enter once more prints out the last 20 etc.

/Håkan

On Thu, Oct 29, 2015 at 8:43 AM, Håkan Mattsson [email protected]
wrote:

The main purpose with the doc tags are to provide a (static) overview of
what the purpose is with the various test cases. A simplified test spec.

Supporting variables in the doc tags would make the "test spec" quite
ugly as most of the variables would only be set while executing the tests.
That is they are not set when the script is preprocessed to extract the doc
tags.

I think a better idea is to allow newlines and tabs in the progress tags.

/Håkan
On Oct 29, 2015 12:13 AM, "jsherman256" [email protected]
wrote:

I prefer the format of [doc] over the format of [progress] for printing
out values that are important to test cases (especially when debugging).
However, the variable is printed out as a string literal "${var}" rather
than printing the content of ${var}

—
Reply to this email directly or view it on GitHub
#6.