Suggestion

[klacke]

Hakan, how hard would this be?

When writing reactive fastmap applications a common scenario for lux tests
is as follows (This applies to any async application, where the results of the
command may take some time to produce)

Using CLI:

!set x y
?[\ok]
set a b
?[ok]
!commit
?[ok]

The crux is that in RFM apps, the result isn't there after commit, it takes some
time to produce. I've now started to craft various custom script for this pattern,

!my-wait-scrip.sh foo bar baz
?WAIT_SCRIPT_OK

Where the script, in a loop, issues a command and expects some data.
Lux could support this, e.g think:

[try-loop 1 20]
!show status my-fastmap foo
?expected-output
[end try-loop]

Which then tries 20 times, with one sec between the attempts. On first success of all commands in the block we're good to go and can continue. I understand that this is exactly semantically the same as

[sleep 20]
!show status my-fastmap foo
?expected-output

Sleeps are really bad though.

Opinions ?

/klacke

[hawk]

The optimal solution would be to make the system under test easier to test.
A subscription mechanism would be very useful in this case. A system
relying on random sleep periods in order to be tested is in my opinion
broken. When designing a system one should also consider how testing it can
be simplified.

With the current loop construct in lux you can do like this:

+expected-output
[loop iter 1..20]
[progress try $iter]
!show status my-fastmap foo
?CLI-PROMPT
[sleep 1]
[endloop]

​Then the lux script would be successful if the expected output is matched,
otherwise it would fail. Does it suffice?​

/Håkan

On Fri, Nov 27, 2015 at 10:16 AM, Claes Wikstrom [email protected]
wrote:

Hakan, how hard would this be?

When writing reactive fastmap applications a common scenario for lux tests
is as follows (This applies to any async application, where the results of
the
command may take some time to produce)

Using CLI:

!set x y
?[\ok]
set a b
?[ok]
!commit
?[ok]

The crux is that in RFM apps, the result isn't there after commit, it
takes some
time to produce. I've now started to craft various custom script for this
pattern,

!my-wait-scrip.sh foo bar baz
?WAIT_SCRIPT_OK

Where the script, in a loop, issues a command and expects some data.
Lux could support this, e.g think:

[try-loop 1 20]
!show status my-fastmap foo
?expected-output
[end try-loop]

Which then tries 20 times, with one sec between the attempts. On first
success of all commands in the block we're good to go and can continue. I
understand that this is exactly semantically the same as

[sleep 20]
!show status my-fastmap foo
?expected-output

Sleeps are really bad though.

Opinions ?

/klacke

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

[klacke]

On 27/11/15 11:00, Håkan Mattsson wrote:

The optimal solution would be to make the system under test easier to test.

All asynchronous systems have this characteristic, it's inherent in
the pattern

1. Execute something
2. wait a while
3. Issue check command, was the data there (yet)

Or,

1. Send UDP packet
2. Wait a while
3. Have we received a reply

A subscription mechanism would be very useful in this case.

That requires adding code to the system, a lot of code.

A system
relying on random sleep periods in order to be tested is in my opinion
broken.

+1

When designing a system one should also consider how testing it can
be simplified.

Disagree, see my UDP example above.

With the current loop construct in lux you can do like this:

+expected-output
[loop iter 1..20]
[progress try $iter]
!show status my-fastmap foo
?CLI-PROMPT
[sleep 1]
[endloop]

​Then the lux script would be successful if the expected output is matched,
otherwise it would fail. Does it suffice?​

I'll be damned !!! re-reading the lux UG, this is exactly what I was
looking for. You're the king hawk !!!

Quote UG

+
+Regexp
Sets a success condition regular expression [regular expression][]. If
the given Regexp ever matches, the test case is considered a success
(no further processing of the script will be performed besides
cleanup). If no Regexp is given, the old success condition is reset
(cleared). It is typically used to match error messages.

In the active shell, the Regexp is tried on the output preceding
each successful match of expect expressions. The characters up to, but
not including, the (successful) match are tried against the success
condition. In non-active shells the Regexp is tried when the shell
produces new output.

/klacke

[klacke]

Hmmm, re-reading once more, and this is close bu no cigarr, when the +expr matches, it seems we directly to cleanup, thus this construct can only be used once in a script, I'd like to use it many time over and over again in the same script.

!request do something
[invoke my-loop-match-macro "show status my-fastmap" "result good"]

!request do something else
[invoke my-loop-match-macro ]

....

[klacke]

[macro async-matcher action pattern]
+$pattern
[loop iter 1..20]
[progress try $iter]
!$action
?CLI-PROMPT
[sleep 1]
[endloop]
+
[endmacro]