Watch closer what SLIM is doing

[six42]

This is an alternative implementation to #1469 from @pvbemmelen62 As it is fully implemented in the Slim Server it will work for all Slim ports and not only for the Java Slim Client as the other mentioned PR.

It adds a new feature to see the instructions SLIM is creating step by step and also see how a SLIM table changes with each execution. To achieve this result the Slim Test System needed a change to suport processing of SINGLE instructions. The existing SLIM implementation always sends a full table to the SLIM client for execution, which I call BULK mode. In the past there may have been performence concernces for the network communication to do it in this bulk way. Nowdays this is not an issue. Modern protocols like the Language Server Protocol or Debug Adapter Protocol work also in a step by step approach to get the best interactive experience. Nevertheless this new SINGLE mode is not active by default. Default is still the BULK mode. Only when more interaction is requested the SLIM test system will switch to this mode.

Usage Guide - From the updated Wiki page

When a SLIM test is run the the webpage will update each time a table has been fully processed. If you want to get quicker an undate you have to set the property: ''slim.show''

At the top of the test page you will then see 2 additional outputs

1. A list of the last 10 instructions the SLIM server is sending to the SLIM Client and the results of the same.
2. The current table and how its cells are updated after each instruction executed.

In addition you can use the following two properties to customize this further:

• slim.show.size - default 10 - Number of instructions to show

• slim.show.sleep - default 0 - Waits for X milliseconds between each instruction call. This is for making nice videos of a test run. Otherwise I don't think there is a usecase for slowing down the execution of your test

Those properties can be either provided by a wiki page, on the command line (e.g. ''-Dslim.port=9000'') or in the plugins.properties file.

Watch the video:

https://github.com/unclebob/fitnesse/assets/5906592/a11fb7dc-b9e4-425a-ac85-a596f9d0b921

Sample Invocation: http://localhost:80/FitNesse.UserGuide.TwoMinuteExample?test&slim.show&slim.show.sleep=90&slim.show.size=15

[pvbemmelen62]

Hi six42 ,

I see a couple of drawbacks in having the slim instructions shown in the run log page itself:

1. the java code is complex, compared to when showing it in a separate window.
2. the slim instructions are shown at the top, but the run log page grows at the bottom: you can't see both at the same time.

And you don't see the currently running instruction , which is a big minus.

Ad 1) The complexity is added in the current code. In #1469 , which uses a separate window, any added complexity is in the code for the extra window. It doesn't add complexity to existing code.

Okay... #1469 uses a Swing window. @fhoeben likes to have a browser window showing the slim instructions. Maybe I will release the "browser version" that I currently have, even if it is not quite usable because it hardcodes the browser port. That way others can take a look at it, and maybe help in adding "a separate option" for specifying the browser port .

[six42]

Hi @pvbemmelen62 Paul, thanks for taking the time and looking at the PR. Following the fitnesse architecture might look complex. Having the reporting happening in the reporting engine I see as an advantage. It should not be done by the SUT. It has the advantage that this PR will work with any language SLIM supports. And it add the feature of the updating tables in real time.

Just showing the finished instructions is a limitation of the current interface design and could be changed by addding one more method to the Interface: TestSystemListener.

If a test is bigger than one page length my browser is not scrolling to the bottom automatically. Is yours doing this? So I anyway never see the current test output with Fitnesse. Showing the new data at the top was a choise to ensure the instructions are always visible. For me it feels better than what was available so far. It could also be appended to the bottom but as said than you are busy with scrolling all the time and can less focus on what the test is doing.

[six42]

Removed the limitation that the instructions are only show after the execution. Now they are first shown as "in progress" and after execution the actual result is added.

https://github.com/unclebob/fitnesse/assets/5906592/7addab43-8f9f-47d9-8cf9-9bf553ff0321

[fhoeben]

@six42 I like the idea of seeing progress as its happening very much. In the past it always bugged me to have to split up a long script table in multiple to have some overview of where the execution was.

Some minor notes. I think we should require a true value for the slim.show property. That makes it easier to configure it always and just changing the value to enable/disable.

Have you checked whether the HTML output generated to file via a jUnit run is changed. I don't expect it, but just wondering.

Furthermore some unit tests and an update of the release notes would have been nice...

[six42]

Hi Fried,

Thanks for looking at the PR. Good remarks.

The XML output stays the same with this design. Additional output is only created in the SuiteHtmlFormatter.java which is only used for interactive usage and independent from the XML Formatter.

slim.show: I kept it in the tradition of other flags like 'debug', where just the presence enables the feature. I also didn't wanted to make it boolean. A use case I could imagine is that you just want to show the instruction list and not the HTML table or vice versa. Maybe leave it like this for the moment and get more feedback from more users to understand the right design.

Test cases: When the feature is disabled all existing test cases pass. This is already a good coverage and result :) Switching from BULK to Single, I run all test cases once and they passed. To not double testing time I don't want to make this part of the standard regression set. In a future release we can make SINGLE rather the default mode. But better to first get feedback from more users which actually use it. For the additional output I also think it is better to get more user feedback before carving it in stone with test cases which check presence of specific HTML tags.

In general I agree with you that each PR should have test cases. In this case I see the status as a disabled BETA feature which will finalise with more users providing feedback.

If you have a test case in mind which you see material at this stage I will add it.

Release notes: I will add if you are good to merge :)