Specflow/Gherkin testing XML documents

Question

We have an ASP.NET/MVC WebApi project with a large collection of end-to-end tests driven by Specflow. All the requests and responses so far have been JSON, so this has been working perfectly.

Now however we have an endpoint that expects an XML body, which ideally we would have as a literal in the feature file...

Scenario Outline:
    Given I am authenticated
    When I post the following XML
    """
    <xml>
        <foo>
            <Bar>
        </foo>
    </xml>
    """
    Then something good happens

Examples:
    | Bar     |
    | apples  |
    | bananas |

The problem is that we make a fair amount of use of Scenario Outline, and the Specflow/Gherkin syntax for injecting scenario example properties looks like XML tags, e.g. <firstName>.

Is there a way to use Specflow/gherkin with XML documents with scenario outlines to, for exmaple, inject Bar with the values in the examples?

Do you really need to have the literal XML there? This kind of low level specification doesn't mesh very nicely with the Specflow approach. Putting arbitrary XML in <Bar> also seems clumsy (escaping will be a pain...) Is it necessary for the reader to actually see the XML to understand the feature? Otherwise, you might consider making it something like When I call feature X with the frobber set to <Bar>, and leave the actual XML to the step implementation. (Note that you have the full machinery of the language available to capture/reuse/build the request in this case.) — Jeroen Mostert
Also, in my test, <Bar> is actually replaced with apples and bananas. This makes it unclear what your actual problem is: do you merely not like that the replace parameters look like tags? Is there a collision between tags and parameter names? — Jeroen Mostert
Yeah, for most of the tests we'll use a step that lets us specify the dynamic bits of the XML, and going that way for the whole thing wont be too bad if we have to, but we tend to have one or two 'happy path' examples that have the literal XML in the feature - it's just nice to refer to. — GoatInTheMachine
Just saw your second reply- I'm not able to test this at the moment, this question is specualtive - if it 'just works' then that's brilliant! It's possibly still a little unclear though. — GoatInTheMachine
@Fran I find that for tests of machine-consumed APIs, having the body of the request explicitly in the feature can have a lot of value without any obvious drawback - although for general testing of the endpoint or it's use in steps of other tests, keeping the body elsewhere is much better — GoatInTheMachine

Charlie Seligman Charlie Seligman · Accepted Answer · 2018-04-20T15:04:06

Personally I would create xml files for each xml sample you need (e.g. fruitText.xml) and pass the filename into the Gherkin. The step definition will then find the file and load the xml into the relevant section of the AUT.

Specflow/Gherkin testing XML documents

1 Answers