Symbols are not stored in the SlimTestContext

[smithap]

If I create a symbol using "let", it's not available in another fixture, say a slim script fixture, as the variables are stored in a different place?

[smartrics]

They are currently not stored in the slim test context but in fitnesse
symbols map. Fitnesse#getSymbol

If I create a symbol using "let", it's not available in another fixture,
say a slim script fixture, as the variables are stored in a different place?

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/52.

[smithap]

Yes, not ideal. A lot of the standard Slim fixtures like the script one, have built in the ability to use the Test Context. If I want to pass variables back and forth, I end up having to write code to simply move them around. Wouldn't it be better if, when running in Slim mode, RestFixture used the same mechanism?

[smithap]

http://fitnesse.org/FitNesse.UserGuide.SliM.SymbolsInTables

[smartrics]

I agree... But i won't implement it unless there's high demand for this feature.

On Feb 5, 2013 10:08 AM, "Adrian Smith" notifications@github.com wrote:

Yes, not ideal. A lot of the standard Slim fixtures like the script one,
have built in the ability to use the Test Context. If I want to pass
variables back and forth, I end up having to write code to simply move them
around. Wouldn't it be better if, when running in Slim mode, RestFixture
used the same mechanism?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-13122498.

[smartrics]

Please re-open if necessary. Unless there's demand for this feature I won't do it

[alvillaflor]

so what is the work-around to be able to use the variables in the rest fixture and make it available on slim fixtures? I too am trying to see if I can get the value.......
something like this? !define var {%restValue%}

[jplambert]

Hi @smartrics

I am looking at the code, both RestFixture and FitNesse, and I am under the impression that the issue with symbols would be into FitNesse rather than into RestFixture.

What I am meaning: we should not use "let" to set values in variables but instead rely on Slim symbols as explained in http://www.fitnesse.org/FitNesse.UserGuide.WritingAcceptanceTests.SliM.SymbolsInTables

(let can still be useful as temp variables in the table to decompose a check of the extraction of a value)

But that does not work because FitNesse passes the symbols to the fixture, which looks to me as something dumb. FitNesse could replace referenced symbols with their values before passing the text to the fixture, and also remove any symbol assignment text. I'll give it a try but it looks like doing so would enable to use symbols in RestFixture (and any custom fixture, for that matter, including my hash fixture introduced in iisue #110).

I'll go even further, a quick look suggests a slightly off design there in FitNesse, because the other fixtures included in FitNesse appears to handle the symbol stuff all by themselves. It would make sense to factor this behavior (substituting referenced symbols with their value, assigning symbols) in the runner rather than in each fixture implementations. But maybe I'm wrong, I should have a closer look at all fixtures before claiming so...

I'll try hacking FitNesse to see if it enables the symbols into the custom fixtures. From there, I'll have to see if that actually make sense and talk about it on FitNesse's GitHub... :-)

What do you think?

[jplambert]

Hey there, I got something working.

The following test works using the hack of FitNesse I suggeted: (DummyFixture simply returns the content of the first column in the second colum, as a way to perform tests oustide of RestFixture)

!define TEST_SYSTEM {slim}

!path dependencies/*
!path smartrics-RestFixture-3.2.jar
!path slf4j-simple-1.6.6.jar
!path DummyFixture.jar

|import|
|smartrics.rest.fitnesse.fixture|

| Table: Rest Fixture | http://localhost:8070 |
| GET | /TestRestFixture?rss | | | //title[text()='TestRestFixture']|
|let|id|js|response.body|$V=|

|Table: Dummy Fixture|
|sometext$V||

|Table: Dummy Fixture|
|root|$Y=|

| Table: Rest Fixture | http://localhost:8070 |
| GET | /$Y?rss | | | |

--> $V and $Y are assigned
--> $V and $Y are replaced by their values

Does that look right to you?

I'll bring the issue over FitNesse to see if what I changed makes sense. Maybe I misunderstood something in the design of FitNesse/Slim. In any case, this requires no change in RestFixture!

Thanks again.

[smartrics]

Hi - well done for the progress.

Preamble. Wherever possible the my approach has always been:

• keep tests compatible between the slim and fitnesse runners. to the extent that it should only be necessary to swap the runner
• wherever an incompatibility must be introduced then this should only be localised and side effects free.

With that in mind, I did look at refactoring smartrics.rest.fitnesse.fixture.support.Variables to handle either fit.FitSymbol or fitnesse.slim.VariableStore. that way the RestFixture encapsulates the two differences.
I never managed to start on the slim variant tho' so, I am not sure / I don't remember whether I proved that VariableStore is at the back of the slim symbols.
Obviously the drawback is that RestFixture would use one syntax that differs from the "standard" as described in SymbolsInTables.

So, Your proposal is more elegant even if it breaks the fit<->slim interop i was trying to achieve.
Anyway - I am ok with breaking the fit<->slim interop link if there's no other way to make RestFixture communicate with other fixtures and the FitNesse guys accept your solution.

Of the picture above am not sure why the output in grey is html formatted. is it supposed to be that way?

[smartrics]

Hi - i have closed #110. Let's keep this one open as more pertinent to the problem we're trying to solve.

[jplambert]

Yes in the picture the output in grey is HTML because it is the content of $V, which has been assigned the response body (HTML) of the first Rest call. FitNesse does a clean job in showing that: "$V <- [...]"

As for using VariableStore, I saw you started thinking about it with a VariableStore field, not used anywhere. But I don't see any way it could work... Unless I missed something, VariableStore is purely local. So using a VariableStore in RestFixture would maybe enable to share symbols between several RestFixture calls (as I believe you did some time ago with local 'let' variables) but not shared with other fixtures. I tried looking at how FitNesse and the Slim fixtures interacts, but I could not see how FitNesse would provide any variable store to the Slim fixtures, and I did not see either any static call that could be made from the Slim fixtures to get some shared variable store (which is good design, by the way). We could always do it using stack trace and reflexion of course, but I am pretty sure we don't want to go this way... ;-)

So basically RestFixture has currently no way to understand symbols defined by other fixtures, nor to define symbols for the other fixtures. Again, unless I'm wrong and missed something.

From there, my conclusion is that either the Slim Fixture contract needs to be changed to provide the variable stores to the Slim fixtures, or the symbols are meant to be handled by FitNesse/Slim server only. Which led to my proposal, by replacing the symbols at the Slim server level and removing the symbol assignment text provided to the fixture (since the fixture could not use this info anyway, not having access to the symbols).

I believe this may be what the FitNesse guys had in mind, since the symbol assignment stuff is already done in TableTable. It's a bit weird then that the symbol replacement was not there, and passing symbols to fixtures without access to the store of symbols do not make sense.

I'll share the link to the FitNesse issue I'll create about the subject and see how it goes.

Also, sorry to break the compatibility between Fit and Slim :-)