PowerSlim | Fitnesse (SLIM) | SpecFlow | |
---|---|---|---|
Web Access | ![]() |
![]() |
![]() |
Test In/Out | WYSIWYG | WYSIWYG | Gherkin scripts are used to generate test fixtures. Actual test results you can view by using Visual Studio Test View interface. |
Verification Code | Verification done by framework itself. You just need to provide the results. | Verification done by framework itself. You just need to provide the results. | You need to duplicate your specification statements again for underlying testing framework (MSTest, NUnit) |
Built in Fixtures | ![]() |
![]() |
![]() |
Visual Studio Integration | ![]() |
||
Force HLT | ![]() |
![]() |
![]() |
Test In/Out
PASSED
FAILED
Verification Code
SpecFlow – check CompareToInstance or CompareToSet examples.
Fitnesse – check method query(). It just returns the results. There are no comparisons/expectations/asserts. Finesse does it for you because of In/Out (see above).
Built in Fixtures
- Built in possibility to call product through public interface
- Built in possibility to see results of such a call
PowerSlim already implemented Fitnesse fixtures (Script, X Query, Scenario, Decision ) for you. So you don’t need to write any test classes to make a glue between your test and production (SUT). All you need is to find a way how to setup testing environment or to call your production through a public interface (command line, PowerShell CMDLets, REST, HTTP). PowerSlim will send the results back to Fitnesse by using SLIM protocol. And the good things is that Fitnesse by himself is responsible for different type of verifications (see Verification Code above).
Example: get-service is all what you need to put in your test to get the idea about the state of a particular service.
Subset Query:Local | get-service | |
ServiceName | Status | DisplayName |
SENS | Running | GO SENS GO |
Visual Studio Integration
I really want to put something for SpecFlow. They did the great job by integrating with Visual Studio 😉
HLT
The requirement to test/call your product through a public interface is still the #1, even if I don’t completely agree with myself back to 2010 http://vlasenko.org/2010/03/17/beyond-acceptance-testing-framework/. It is not an Acceptance Tests if you need to mock part of your product. Probably this one is not a bad unit test (Stop Mocking, Start Testing)