ExternalData plugin raw JSON

[namtab00]

I'm trying to use the JSON functionality of the ExternalData plugin.

It seems to be no way to pass to a binding the raw JSON instance, as a string or deserialized POCO, read from an array from the source JSON file.

I find it strange that this hasn't come up as a necessity, but then again it might be that what I'm trying to do is strange.

I can only pass explicit object props, as explained by the docs.

Given this json file contents:

{
  "createDtos": [
    {
      "active": true,
      "Id": 1,
      "name": "Thing 1"
    },
    {
      "active": true,
      "Id": 2,
      "name": "Thing 2"
    }
  ]
}

I'd like to be able to pass the entire JSON object as a string to a Binding. Something like:

@DataSource:test-data.json @DataSet:createDtos
Feature: MyFeature

Scenario: I want to test that a thing is create
    When I try to create a thing from <RAW_JSON_FOR_THING1>
    Then I should have a response

[gasparnagy]

I'm not sure you really need a plugin for this. I did such things earlier in a way, like:

Scenario: I want to test that a thing is create
    When I try to create a thing from "test-data.json"
    Then I should have a response

And in the When step definition you simply read the file.

You can also make a simple JsonFileContent class that represents the loaded json file and make a transformation that processes the file loading:

public class JsonFileContent {
  public JObject RootNode {get;set;}
}

[StepArgumentTransformation("\"(.*)\"")]
public JsonFileContent LoadJson(string fileName) {
  return new JsonFileContent { RootNode = /* TODO: load JSON based on file name */ };
}

If you do so, your step definition can look like this:

[When("I try to create a thing from {JsonFileContent}")]
public void WhenX(JsonFileContent json) {
  // work with json
}

[namtab00]

@gasparnagy it's that "load JSON based on file name" that's covered in a unified and "cleaner" way by the ExternalData plugin.

Having the referenced data sets spelled out via the plugin's binding tags makes for, IMHO, a clearer way of human-reading feature files.

Thanks for the workaround though.
I'm using Reqnroll because some other previous dev set it up in my project, I'm not experienced with it and I'm not entirely sure I like it and its workflow in VS...

[gasparnagy]

Yes, having that clarity would be also useful in your case, but altogether the two need is quite different:
The external data plugin loads the json (and all other) files compile time. Processes them and extend the Gherkin structure with additional examples based on that. Because this happens compile time, during execution (when the steps are invoked), the file content is not loaded anymore so it cannot be passed to the step. The only possible solution would be to embed the entire file as string into the generated c# code behind file and parse it again to json to be able to pass it in to the step.

We could make a plugin for your need as well, but that would be a runtime plugin and would just simplify the file access based on tags. You can check the external data plugin code, but I think the code parts that resolve the file path based on tags is fairly small. So altogether the two thing would be quite different.

But I'm not against it. If you feel like you are interested, you can play with the external data plugin and see if you see an easy option to pass the json to a step and make a prototype.

Concerns about the Reqnroll workflow (in VS?): I'm not exactly sure what you mean by that.

[namtab00]

OH! Ok, it didn't occur to me that the plugin reads the referenced external data and embeds it on compile in the feature "code-behind" generated code as test data.
I concur it would be a bit strange to embed the entire json file as string in the generated code.

I'll have to explore the plugin source to see how the relative file path resolution and data loading works, to replicate it in my code if I want to store the JSON data outside the feature file.

Maybe what I'm truly asking for is a "JSON file helper", something akin to the DataTable Helper, but that would allow to specify a relative file path (and perhaps a JSONPath for drilling in the file data). The helper would then pass the data as a string to bindings that reference it.

But this too would imply compiling the test data on compile time... I'd find it useful if there was a way to only load the helper provided data at test runtime.

Concerns about the Reqnroll workflow (in VS?): I'm not exactly sure what you mean by that.

What I meant is I'm not familiar with the dev ex steps when using Reqnroll in Visual Studio 2022.
Having to fix / refactor some tests, I find myself spending A LOT of time manually renaming test methods to align them with changed binding names and such.

Surely I'm a case of "you're using it wrong", but I'm not sure where I can find a guide to how to perform common operations with VS (for example: rename/regenerate associated binding names in feature files when renaming a StepDefinition method name, and viceversa). The official guide is "in progress"...

[gasparnagy]

Sure.

The rename is a pain, indeed. The VS extension provides a rename command but it is pretty limited currently. Could be improved for sure.

I usually try to have an agreement on the scenario text before the automation starts, so that I need less renames. If you ignore the method names, the step text can be renamed with the regex based replace in files feature of VS though.