If verbose via slim.flags -v, then popup window that shows slim instructions.

[pvbemmelen62]

If slim verbose is enabled, then popup Swing window that shows slim instructions as they are executed.
Enabling verbose is either via
!define slim.flags {-v}
or via
path.of.test.script?test&slim.flags=-v

The slim.flags -v option is an existing option. Up until now it only wrote the slim instructions to stdout, and they were shown in Execution Log after the script finished.
Maybe its better to have a separate slim.flags option, for example -slimview , to show the Swing window.
Maybe its better to have a SlimListener interface, and static method ListExecutor.addSlimListener , to not have Swing code called directly from within ListExecutor.
I'm happy to receive any feedback on this.

[six42]

Hi Paul,

Not sure if you noticed this: If you run a test with verbose enabled and you look at the "execution log" (green button)
you can see the instructions in the "standard output" section

Execution Log

[pvbemmelen62]

Hi six42 ,
I know about the slim instructions being shown in Execution Log after the run.
But I want to see them as they are being executed; that way I can better understand what a test script is doing at any particular moment.
Ideally you'd want to see the Fitnesse commands as they appear in the test script, rather than the slim instructions, but I don't know how to achieve that.

[six42]

Hi Paul,

What are for you the "slim instructions" and the "FitNesse Commands". Can you give an example?

To get StdOut in your TestPage output you can do this:

1. Add ExecutionLogListener interface to SuiteHtmlFormatter

public class SuiteHtmlFormatter extends InteractiveFormatter implements Closeable, ExecutionLogListener 

2. Implement the stdOut function from the interface

  @Override
  public void stdOut(String output) {
    writeData(output);
  }

This still might break the HTML page created because

1. You should add code to escape "output" to remove anything which looks like HTML.
2. Function testOutputChunk might not output a full html object at once but just a chunck. If stdOut adds text before testOutputChunck has a full HTML object you get something unexpected.

[pvbemmelen62]

Hi six42,

A Fitnesse command is
|click|Uitgebreid zoeken|
and its slim instruction might be
[decisionTable_344_0/scriptTable_272_1, call, scriptTableActor, click, Uitgebreid zoeken]


You describe how "To get StdOut in your TestPage output" , but that would interleave slim instructions with Fitnesse table results, and would be messy, I guess.

Can you comment on the code that I wrote as part of this pull request ?
Is it something that could make it into the main project ?

Kind regards,
Paul van Bemmelen.

[six42]

Hi Paul,

you can see the FitNesse commands in "near realtime" on the wiki page if you run the test from the wiki.
Do you run your test differently that this doesn't works for you? Or as the wiki mostly updates only once a table is complete this is not granular enough for you? You want to see it row by row, cell by cell? I agree this would be nice.
Would it be enough to just see the last command started?

I initally thought that you wanted to better understand which java functions are currently called. Looks this is not your goal.

Please explain what your real problem is and what you ideally want to achieve. Maybe this is possible and you don't have to live with the workaround of showing instructions.

[pvbemmelen62]

Hi six42,

I want to see each command as it is being executed. Only once the table is complete, is too late; some tables have many commands, and you have to wait a long time before you get feedback.
Also, running other peoples scripts, a script is easier to understand, when you see at any given time, what the script is doing.

I'm not interested in the java functions called; I want to see the commands (i.e. lines) from a script as they are being executed.
I don't know how to show those commands; but slim instructions provide nearly the same information, and I know how to show them.

Surely, it's not a strange feature to want.

[fhoeben]

@pvbemmelen62

• I would indeed prefer a separate option, more explicit to what will happen
• Could you investigate whether it would be possible to do it via a new browser tab/window instead of via Swing? That way it can also work for users accessing FitNesse on another machine (or from Docker).

[pvbemmelen62]

@fhoeben
I don't know how to implement it via a new browser tab/window . How does one show a webpage and update it as it's contents grows ? Fitnesse knows how to do it, but I don't know how complex the code is that achieves that; and if I should reuse that code or not.
With respect to Docker:
Q: What would happen with the Swing implementation ? Would the Swing window be inaccessible, invisible ?
Q: And how would a browser window be accessible from Docker ?

Two other considerations:

• scrollbar control as provided by SmartScroller.java : is something similar possible for a browser window?
• the browser window must be small enough to allow seeing both that browser window, and a good part of the application being tested; preferably the browser window must have its own window, not being a tab in an existing window.

Pointers to example programs, Fitnesse class files, or relevant documentation, are welcome.

[six42]

Hi Paul,
i looked how to do this and I created a branch in https://github.com/six42/fitnesse/tree/sbys with a proof of concept.
At the top of the test it always shows the last instruction and optionally the current table as it gets updated after each instruction.

The end result doesn't looks as useful to me as expected. What is your view?

This Video shows that the execution is in normal cases too fast and nothing is really visible:

FitNesse_StepByStep.mp4

In this Video I added an extra delay of 500 ms after each instruction to see the effect:

FitNesse_StepByStep_slow.mp4

General Instructions:
Two new parameters can be given on the command line to see what fitnesse is currently doing
1)
A) slim.sbys=SHOWTABLE
show the html table after each executed instruction
B) slim.sbys=SHOWINSTRUCTIONS
show the instruction after each executed instruction
C) slim.sbys=TRUE
instead of sending a full tabke to the slim client send just one instruction each time
2) only if 1 is given, will delay the execution by 0.5 seconds just useful for showing the beaviour
slim.sbys.sleep=SLEEP

Examples:
http://localhost/FitNesse.SuiteAcceptanceTests.SuiteSlimTests.TestComparators?test&slim.sbys=SHOWINSTRUCTIONS&slim.sbys.sleep=SLEEP
http://localhost/FitNesse.SuiteAcceptanceTests.SuiteSlimTests.TestComparators?test&slim.sbys=SHOWTABLE&slim.sbys.sleep=SLEEP

[pvbemmelen62]

Hi six42 ,

The approach that you demonstrate above, requires much more detailed knowledge of the Fitnesse source code.
You have to change 8 files .

The approach that I used in my pull request, is simpler: The slim instructions are shown in a separate window, and the existing run log window is unchanged.
I only have to change ListExecutor . And add a LogView.java and SmartScroller.java .

I'm trying to come up with an implementation showing the instructions via a webbrowser instead of via a Swing window, just as fhoeben requested. I'm planning to use HTTP chunked transfer encoding ( https://en.wikipedia.org/wiki/Chunked_transfer_encoding) , which is also what Fitnesse uses for it's run log browser window.

You write

The end result doesn't looks as useful to me as expected. What is your view?

I like the table being shown, and that it is being updated as instructions are run. The slim instructions at the top are only very briefly visible, though. The "Instruction {id='NOOP'}" stays visible long enough for me to be able to read it, but the instructions that call a method, are gone very soon. They don't scroll ; if they would, they would remain visible.

For a moment, I thought ... "Who needs to see the current slim instruction, when you can see in the Fitnesse table in the run log where the script currently is executing?" . But I think the current slim instruction is the best thing to show: the table in the run log is only updated with the color for the line just run, after the line has finished executing. And if the line is collapsed, it may represent many slim instructions.
So: yes, we do want to see the slim instruction that is currently executing.

[pvbemmelen62]

@fhoeben
On 2024 jan 22 you write

* I would indeed prefer a separate option, more explicit to what will happen

* Could you investigate whether it would be possible to do it via a new browser tab/window instead of via Swing? That way it can also work for users accessing FitNesse on another machine (or from Docker).

I now know how to implement doing it via a browser window. It's a bit more complex than the Swing solution. I haven't made that code available yet, because I don't know how to implement a separate option.

And how should I make the code available? As a new pull request , or as changes to the current pull request? I know how to do the former, the latter I'd have to find out.

Currently I have the port that the browser must connect to, as in localhost:<port> , hardcoded to 3456 .

I don't know how to implement the separate option that you mention; I think that would be a command-line option to specify the port for the browser.
How do I pass such an option , e.g. slim.debug.port=5678 , to ListExecutor ?
I guess it would be done in a fashion similar to the verbose argument in the ListExecutor constructor:
protected ListExecutor(boolean verbose, SlimFactory slimFactory)
But exactly how the verbose argument is handed down from higher up, I am unable to understand; the code is too complex.

[six42]

Hi Paul,

a different thought.
There is the fixtureInteraction Hook.
Did you considerd this to add your your output code.
Would avoid any new option.
it is a bit more low level information you get there. Might be better or not for your purpose.

To try it, add this to any test page:
!define slim.flags {-i fitnesse.slim.fixtureInteraction.LoggingInteraction}

Define than your own class to customize the output to your needs.

[pvbemmelen62]

Hi six42,

Interesting possibility, using my own fixture interaction class.
I ran a script using the LoggingInteraction class that you mention, but find its output somewhat harder to read than the slim output.
The output from LoggingInteraction class also shows calls to aroundSlimInvoke ; they don't correspond to any lines in a Fitnesse script.
I don't know if it is easy to produce easy-to-read lines from within my own fixture interaction class.