earloc/postomate

A library to automate and orchestrate requests out of a postman-collection with .net

postomate's Issues

Provide convenience-methods for usage in SpecFlow-scenarios

When using SpecFlows ScenarioContext to find requests, there should be an easier way to find matching requests based on the current context.

E.g.:
When executed in a scenarios steps, we currently need to deep-dive into the current scenario-context in order to gather the needed information to find a matching request, e.g.:

var request = featureFolder.FindRaw(scenarioContext.StepContext.StepInfo.BindingMatch.StepBinding.Regex, variables);

This should be shortened significantly, preserving the possibility to leverage either a simple stringor a RegExfor finding requests.

Maybe this would be OK to do via special extensions/overloads, which accept a ScenarioContext or so in

postomate/src/Postomate/Postman/RequestFolder.cs

Line 46 in c5e14a8

public RawRequest FindRaw(Regex regex, IVariableContext? context = null)

and

postomate/src/Postomate/Postman/RequestFolder.cs

Line 49 in c5e14a8

public RawRequest FindRaw(string name, IVariableContext? context = null)

.

However, this possibly would need to be done in a seperate Postomate.Extensions.*-assembly.

Showcase best-practices when authoring postman-collections

When authoring parameterizable postman-collections, we end up in collections containing requests that for themselfs might not be executable anymore.

E.g.: the following request is not executable without specifying values for the given variables (like via an environment?!):

We need to ensure that Postman knows about the two variables firstName and surname.

When automating these requests, this is quite straight forward, by leveraging one of the IVariableContext-implementations:

variables = new ImmutableVariableContext(new {
    baseUrl = api.BaseAddress?.ToString().Trim('/') ?? "http://localhost:5042"
});

and later:

 var createArthurRequest = folder.FindRaw("PostPerson", variables.Enrich(new {
    firstName = "Arthur",
    surname = "Dent"
}));

However, we lose tha ability to just fire the request out of Postman itself, without finding a good way to actually specify values for the variables.

The current way is to add a pre-request script, which fills the variables with appropriate values prior sending the request.
Is there another, better way? Especially to ensure completeness (that is, ensuring that every possible variable actually gets a meaningful value?)...

Regardless of the above question, this approach should be documented in the repo´s readme.

Extend readme with samples for usage in SpecFlow-tests

Showcase the usage of this lib in the repo-readme, when using SpecFlow-tests.
A running sample can be found in here

Extend readme with samples for usage in unit-tests

Showcase the usage of this lib in the repo-readme.

Enable support for graphQL-requests

graphQL-requests are currently not enabled.

In order to support these, the draft-implementations should be included again, see GraphQlRequest.

In order to close the issue, there should be:

• the actual implementation
• testcases ensuring functionality
• ideally, a graphQL-endpoint in the Postomoate.Tests.api-project
• some samples in the postomate.postman_collection.json

harmonize gh-actions

Currently, there are two build-yamls, which only differ in their trigger:

main.yaml

on:
  push:
    branches: [ main ]

pullrequests.yaml

on:
  pull_request:
    branches: [ main ]

this should be harmonized somehow:

• restore packages
• build
• test
• upload coverage-report

Later, there should also be some steps/actions for pushing everything into NuGet, but that is probably a new gh-actions?!

Decouple parsing of postman-collections from internal representations

The current parsing that is done directly in the core models (RequestCollection, RawRequest, etc. seems to be too coupled on the actual postman-schema.

In order to maybe support other sources, like e.g. Insomnia or SOAP-UI, the actual parsing of source-requests should be decoupled in a way that is more extensible.

Work done in this issue should also relocate the models from the Postomate.Postman-namespace into the root namespace Postomate, denoting a breaking-change. Gladly, there is no official package out, yet - so this is absolutely a no-brainer.

The resulting design should presumably abstract away the details needed to fill the models, regardless of the actual source - even if the only source currently is a postman-collection.

Provide initial documentation

Readme should explain a few things:

• Synopsis, what's it good for?
  • e.g. current lack of support for "flows" postmanlabs/postman-app-support#1535
  • decoupling tests from their respicitve implementation (which enables a test-first approach)
• how to get started
  • #13
  • #14
• how to contribute

Publish NuGet-package(s)

There should be an official NuGet-package available for consumers to pick up.

A good baseline is available via #8. Now we should actually publish the stuff into the feed for others to consume!

Enable support for form-url-encoded-requests

Form-url-encoded-requests are currently not enabled.

In order to support these, the draft-implementations should be included again, see FormUrlEncodedRequest.

In order to close the issue, there should be:

• the actual implementation
• testcases ensuring functionality
• ideally, an endpoint in the Postomoate.Tests.api-project
• some samples in the postomate.postman_collection.json

Leverage existing assertions from postman-requests

Would be cool, if we somehow could leverage existing assertions made within postman after firing requests. This way, the need for custom parsing and asserting on responses could be relaxed in a way, that drastically reduces boilerplate in the test-code