Symbol names concatenated with text don't work in the Java Agent

[six42]

The below junit test claims that the slim test below should work. But the slim test must fail as the slim agent doesn't implements this logic. Does other slim agents other than Java implement this?

To make concatenation with text work I would like to change the symbol pattern to allow an optional $ to mark the end of the symbol name. What do others think about this?

Junit: test\fitnesse\testsystems\slim\tables\SlimTableTest.java replaceSymbols_ShouldReplaceConcutenatedSymbols

Slim Test which fails: |import | |fitnesse.slim.test|

|script | |$X= |echo int|99 | |check|echo |$X |99 |pass| |check|echo |$X1 |991 | fail| |check|echo |$Xabc|99abc| fail|

New proposed Syntax: |script | |$X= |echo int|99 | |$y= |echo int|7 | |check|echo |$X |99 | |check|echo |$X$1 |991 | |check|echo |$X$abc|99abc| |check|echo |$X$$Y|997|

Finally I feel that this test is not doing what he claims. I can't see in the code that $$ is implemented anywhere. Is this used by other non Java Agents? Otherwise I would remove this test. http://fitnesse.org/FitNesse.SuiteAcceptanceTests.SuiteSlimTests.SlimSymbolDollarDollar

[ggramlich]

The sentence

$$ should prevent symbol expression and reduce to a single $.
So $$a should translate to $a.

from page http://fitnesse.org/FitNesse.SuiteAcceptanceTests.SuiteSlimTests.SlimSymbolDollarDollar is wrong. This stems from a very short period where this behaviour was active and described in the Slim protocol.

See

• https://github.com/unclebob/fitnesse/commit/e94ceb7267340d9f4441644eb680892832eb76e0
• https://www.pivotaltracker.com/n/projects/44141/stories/2471066

The issue was semi-publicly discussed via e-mail. I just put the thread into a pdf: https://drive.google.com/file/d/0B1_04a8eUvOwM0h2UGhQOHNwZVU/view?usp=sharing

[six42]

Thanks Gregor for the details about $$. This answers half of my question.

Anybody knows something about concat? does other slim languages depend on this?

[six42]

Hi Gregor,

In the documents you provided was also a discussion about escaping the symbol pattern. Was there any solution found?

[ggramlich]

@six42 No, as far as I remember, the changes were just reverted - no more escaping. See https://github.com/unclebob/fitnesse/commit/e0696

[jplambert]

From my experience, the rules that match the name of a symbol are not clear. Depending of the text around, it might work or not.

For instance we used to write symbol names in snake_case. It worked well until we found out that it might not work if embedded with some text around -- sorry I don't have the exact example at hand. So now we use the symbol names in camelCase and we don't have this kind of issue anymore.

Still I agree with your proposal to add a way to delimit the name of the symbol. But I'd rather recommend to use the same syntax than for Shell variables: $var ${var}

I think that would be:

• Easier to implement (no optional symbol stuff)
• Clearer to read and use (is the '$' denoting the optional end of the symbol name or another symbol?)
• Easier to pickup since it re-uses an already common syntax (script shells variables)

[jplambert]

... Wait, am I not saying dumb things? ${var} is already used to use variables!!!

Sorry...

[six42]

Agree fully with you @jplambert. But a nice pattern like $[] or %{} would be less compatible. So I think only something for Slim2. $SYMBOLNAME$ in addition to $SYMBOLNAME would maybe break some test but not many. And any break could be fixed with just adding one more $. :+1:
Would at least be cleaner than the current unpredictable, unreadable and non working concat logic.

if no powershell or .net user heavily depends on this we could dare it.

[jplambert]

@six42

Well, so far, it is kind of a non-issue for us. I mean, it is clearly poor design on FitNesse's side, but we managed to live with it by using camelCase to name our symbols.

Unless I am missing something, you can always rename your symbols -- they are specific to your wiki, you have full control over them. Sure we lost time at the beginning discovering and then renaming our symbols, but now we know it and it's over.

So I'd rather say: shall we do things right or do nothing at all? I am feeling like FitNesse is now an old tool, and its age shows -- in things like that. Adding what you suggest won't really improve FitNesse: it will still have many quirks that makes you hate the tool when you use it everyday.

(Disclaimer: I am a daily user of FitNesse and I love the tool. Well, using it extensively has made it become some kind of love-hate relationship. I am also looking what other tools are available out there and seeing tools with a regular syntax and a coherent behavior makes me want to switch tool.)

So, to conclude.

• I believe FitNesse needs an overhaul, but I don't see it happen.
• I don't think the change you propose is worth it, just use camelCase to name your symbols.
• Having said that, I see no objection in adding the feature to FitNesse if you do the job :-)

By the way, if we change the way FitNesse handles symbols, we can also provide some automatic migration tool that would solve the compatibility problem.

[six42]

Thanks for sharing your thoughts @jplambert ,

The coding is already done. But I commented it. Just wanted to get feedback first. But writing a migration tool is more than I can do.

What are the top three items you would like to see changed in FitNesse? If many people feel the same I am sure we can get momentum to get them fixed.

[jplambert]

@six42 I'll gladly review your code.

That's OK not to write a migration tool. I don't think it is worth the effort anyway, even if we changed the symbol handling in FitNesse it would not be much work to update it in a given test base by hand.

What are the top three items you would like to see changed in FitNesse? I don't know, some of my top items are not directly related to FitNesse...

• In one team we are doing PHP, so we use PhpSlim to execute the FitNesse tests. We encounter many issues with this test runner. The biggest one is that the individual tests are not sandboxed and so when something goes bad in PHP, the whole PHP process gets killed (including PhpSlim) and it is thus very hard to understand what went wrong. The problem definitely is in our code or in our environment, but PhpSlim's architecture do not make it easy to pinpoint the problem. This is not directly related to FitNesse itself. We should fix this ourselves but, you know how it is, we have something working now and it is hard to find time to spend on the tooling...
• When such things happen, the Jenkins report says "everything's fine, all 5 tests are OK" while we actually had 40 tests! This can be very annoying as the external notifications won't say clearly that something went bad and that the CI needs attention. Again this is not directly related to FitNesse itself, as when it happens in FitNesse only we have some yellow bar on top: FitNesse says that something went wrong. I believe we could have a proper behavior by spending time on the Jenkins plugin but, again, it is hard to find the time.
• Now for the "bad things" about FitNesse itself. The way symbols and variables are handled are one thing. Two very different concepts, two different syntax, but so similar that you'll be mistaken for sure. We should have two clearly different syntax, and each syntax should have at least one form with a start and end delimiter to make sure we can use the symbols and variables un-ambiguously in any context. Also, the symbol assignment should be handled in every table. It does not work very well in query tables.
• The "empty cell" behavior is, like, different in every kind of tables. Sometimes it means "whatever, I won't check". Other times it will be "if the result is empty, great I mark it as a success as I was expecting it; if it is not empty then I'll ignore it". Other times it will be "that must be empty!" Now the tricky part is, that to make sure the cell is empty, you have workarounds. One is defining a variable whose test is empty. This will work in some tables, not in other ones. The other workaround is to use a regex matching an empty string, which is just ugly, especially when it is needed only in some tables.
• We are annoyed all the time with "URL-like" strings that gets interpreted as links. So we end up escaping these links. But it can be very tricky, because if you add '!' at the beginning of the table, the variables won't be resolved either, and we use them extensively. So we have to specifically escape the URL part with "!-...-!". All this is very counter-intuitive: I have to explain it extensively to all team members. In conclusion, I'd be happy if links were added only on demand, using "[...]", not pro-actively by FitNesse.

There is also a big item that I don't like in FitNesse, but I don't think it can be changed because it is at its core:

• People write "FitNesse code" and believe that is the test; the HTML page being simply some pretty-print for easier reference and use as a doc.
• But in reality, what they write is some commands for the HTML generator, and the test is the HTML itself. That is exactly why when the text of an URL is made into an HTML hyperlink, then the fixture code gets to have some HTML code passed to it, instead of the text of the URL.
• The same happens with variables. If your variables contains some dynamic stuff (something that generated the current time for instance), people tend to believe that using the variable twice in the test page is OK, because "the call is factored in a single variable, so it'll use the same time twice." Truth is, what will happen being the scene is simply code replacement, like a macro. So the actual behavior is that the "call" will be duplicated everywhere the variable is used. So the time may change with each use of the variable.

All this makes sense once you know how FitNesse works (and have some frequent reminders). The problem is that it is simply not the way people instinctively think that it works. It makes using the tool frustrating, and time is lost writing and maintaining tests.

[amolenaar]

@jplambert I think we're pretty much on the same page here. Esp. the fact that Slim deals with the HTML page, instead of the wiki text for test execution makes it hard to understand what's going on under the hood (which is also your 5th point basically). If that only could change...