Mar 12 2010
FIT vs SLIM
I got this question from a blog reader recently:
I just wanted your opinion on SLIM as opposed to standard FIT/Fitnesse. Are there things that can only be done via the FIT/Fitnesse route that cannot be done via SLIM? So for acceptance tests and integration tests can I just use SLIM?
We want to exploit the BDD abilities of Scenario tables in SLIM. Ideally I would like to use SLIM to undertake all kinds of tests. I assume it has all the same capabilities? Are there any issues?
On the face of it, SLIM seems to be the preferred way forward for new FitNesse implementations as it is being actively developed and maintained by the same folks who develop FitNesse. FIT is a bit of an orphan at the moment, Rick Mugridge and I were talking about taking over that integration and enhancing it.
In terms of features, SLIM gives you better compatibility across platforms because a lot of the test system responsibility has been taken over by FitNesse itself (parsing HTML, deciding how to interpret a table, storing and reading symbol values). Watch this video for more information about the differences in responsibilities.
On the other hand, because of the way SLIM works, fitlibrary flow-mode interaction is practically impossible. Most of my clients still use flow mode tests as that is a great way to write and maintain a very thin fixture layer for complex tests.
SLIM also allows you to use Scenario tables, as you mentioned. Scenario tables give testers a lot more power as they can script multi-step execution and compose lower level fixtures into higher level tables, without involving developers to do the same in fixtures. Depending on your environment and team, this might or might not make sense. For covering and existing system with regression tests, it probably does. For using acceptance tests as a guide for development, beware of overdoing it. I am very concerned about long-term maintenance costs of such tests. What happens in this case is that people are effectively programming with tables – doing the same in code would allow you to benefit from IDE support for refactoring, file management and all sorts of other things that make IDEs useful. You lose all that by using scenario tables in order to make testers a bit more independent. I would rather suggest training the testers some basic coding skills so that they can write fixtures.
 |
 |
With some programmitc tricks you can get similar style tests using Slim as you get when using FlowFixtures from FitLibrary. This does heavily rely on a static storage of some kind.
We implemented an test object registry, where several test objects may be stored to using a name. By then you can spread knowledge between tables, while still making the test tables themselves readable.
Script tables provide a similar way, but for my taste they make the tests less readable than flow mode tables. Recently I saw an approach using Library Fixture initialization, that seemed to provide a similar test structure as flow fixture tables, but I haven’t used them myself. (Saw them in some acceptance test for FitNesse itself, while wokring on it).
About the only thing that SLIM lacks with respect to fitLibrary is the ability to return a fixture from a fixture and thereby change the way subsequent rows of a table are interpreted. Other than that, script tables provide a flow mode that is almost identical to DoFixture. YMMV.
Sharing context by returning fixture from a fixture and automatically wrapping arrays and other collections is where I get the benefit from flow mode. That’s also crucial for parallel test execution, as the context is local and not static.
Agree! We need to use them carefully. They are useful for simple remove duplication.
They also useful for other cases…But the scenario itself should be simple and readable.
Example with the duplication:
!*> Test Setup
-!|script|PowerShell|
|eval||Start-Service MyService1|
|eval||Stop-Service MyService2|
|eval||netsh advfirewall firewall delete rule name=MyProductionRule|
*!
Example with the removed duplication:
—-Scenario Library——-
!|scenario|execute|script|
|eval||@script|
——————————–
!*> Test Setup
-!|execute|
|script|
|Start-Service MyService1|
|Stop-Service MyService2|
|netsh advfirewall firewall delete rule name=MyProductionRule|
*!
@Konstantin – if this is something that has to be done for a bigger business test to work, i’d hide it in a fixture and make the fitnesse page easier to read and understand. if this is your whole test, you will be able to maintain it a lot easier in a technical testing tool. the benefit that fitnesse gives you – communication with budiness people, is completely lost there
@gojko I don’t need an additional testing tool. Finesse enough for me.
We don’t use Finesse as a collaboration tool with the stakeholders.
We had used Fitnesse for collaboration before (it is another story…don’t won’t to rise this philosophical question here).
Right now we are using it as Acceptance Testing Framework. Fitnesse is powerful tool for Acceptance/Regression testing.
Having recently started learning Fitnesse starting out with Slim, I can tell you that Slim is not capable of handling anything but the simplest of tests. It is definitely NOT true that the only thing that Slim is missing is flow mode.
The thing that really burned me was the fact that all matches were done after conversion to string. I wasted lots of time getting my expected values to be in the right format to match what the SUT returned. E.g. The SUT returned 5.0, the expected value was 5. Dates were also a killer. You copy your tables to excel and back and you’re screwed fixing it all over again because Excel did not preserve your formatting of the value.
It seemed like I was working for Slim instead of it working for me.
Unfortunately, FitLibrary is no picnic either. There is a great deal of power, but very little documentation, lots of variation between implementations, and a steep learning curve. It is also hampered with trying to maintain some backwards compatibility with Fit.
I think the time is ripe for a new framework that blends the best of both worlds and that does things the right way and does not care about backwards compatibility.
When using fit, I can compare images via ImageFixture, but it seems not possible in slim. Can you give me some help? Thanks very much.
fitlibrary is opensource, so you can take imagefixture and convert it to slim