fastn test helpers

[amitu]

-- fastn.failing-action: /action/create-account/
username: amitu
username-error: amitu username is already take
password-error: This field is empty

-- fastn.action: /actions/create-account/ -> /dashboard/
username: amitu
password: awesome-password

-- fastn.redirect: /foo/ -> /bar/

-- fastn.view: /view/dashboard/
username: amitu

{
    "username": "amitu",
    "user-id": 1,
    "posts": []
}

Also integrate with https://github.com/alexcrichton/libtest-mimic to show better terminal output.

[harshdoesdev]

fastn test helpers

• fastn.failing-action
• fastn.action
• fastn.redirect
• fastn.view

fastn.failing-action

• Accepts:

  • caption endpoint: url of the endpoint.
  • multiple other request params that the endpoint is going to accept. Issue
  • for each request param, there can be a corresponding -error param which is going to represent the error state/message of that param.
    eg: for username there would be a corresponding username-error, which will contain the error state/message received from the response.

• Example:

-- fastn.failing-action: /action/create-account/
username: amitu
username-error: amitu username is already take
password-error: This field is empty

fastn.action

• Accepts:

  • caption endpoint: url of the endpoint or the url and the redirect url for the action.
    eg. /actions/create-account/ -> /dashboard/ means the user will be redirected to /dashboard/ on success of the action.
  • multiple other params that the endpoint is going to accept. Issue

• Example:

-- fastn.action: /actions/create-account/ -> /dashboard/
username: amitu
password: awesome-password

fastn.view

• Accepts:

  • caption endpoint: url of the endpoint
  • body response-data: the response that we will get from the endpoint will be matched against this.
  • multiple other params that the view endpoint is going to accept. Issue

• Example:

-- fastn.view: /view/dashboard/
username: amitu

fastn.redirect

• Accepts:

  • caption redirect: a redirect declaration in a format similar to the one that is already in use for defining redirects in fastn, the arrow format a -> b.

• Example:

-- fastn.redirect: /foo/ -> /bar/

Issues

Issue 1: Allowing users to pass any header/key-value

We are currently defining the test helpers in default_test_bag like any other component and because currently we cannot allow the users to pass any headers or key-values other than the one already defined in the component definition passing username: name will fail.

Proposed solution:

-- fastn.view: /view/dashboard/

-- fastn.view.response:

{
    "username": "amitu",
    "user-id": 1,
    "posts": []
}

-- fastn.view.queries:

-- fastn.query: username
value: amitu

-- end: fastn.view.queries

Issue 2: Passing Cookies or Setting Environment Variables

Should the user be allowed to pass cookies for the request or set environment variables for that particular test case? Eg. DEBUG_LOGGED_IN=admin.

[harshdoesdev]

@amitu, I have mentioned a few issues (along with proposed solutions) in the above comment. Could you please review them?

[amitu]

Issue 1: I would prefer we make what I have written work. This issue is about ergonomics/readability, and what you have written has pretty poor ergonomics. Can we use P1 parser? Can we create some flag in component definition, say ignore unknown keys? @Arpita-Jaiswal any suggestions?

Issue 2: No. We should, as much as possible, try to follow end user's behaviour. So cookies should be preserved from request to request (cookie set by one response must be sent in the next request).

[harshdoesdev]

Okay. I will look into it.

[Arpita-Jaiswal]

Issue 1: I would prefer we make what I have written work. This issue is about ergonomics/readability, and what you have written has pretty poor ergonomics. Can we use P1 parser? Can we create some flag in component definition, say ignore unknown keys? @Arpita-Jaiswal any suggestions?

Issue 2: No. We should, as much as possible, try to follow end user's behaviour. So cookies should be preserved from request to request (cookie set by one response must be sent in the next request).

There's a possible solution for issue 1 where the syntax suggested by @amitu can work. I have conveyed the solution to @harshdoesdev

[harshdoesdev]

Special Flag $allow-unknown-keys$ on ComponentDefinition

We can implement a special flag $allow-unknown-keys$ similar to $always-include$, but only for components, which will allow users to pass key-value pairs that were not already defined on the component. These values can only be of kind string (for now). Additionally, we can store these unknown keys in a separate map called additional_arguments on the Component, allowing us to iterate over them whenever required.

Then, the user can pass any number of properties:

-- fastn.view: /view/dashboard/
username: amitu

{
    "username": "amitu",
    "user-id": 1,
    "posts": []
}

@amitu @Arpita-Jaiswal

[amitu]

Sounds good overall.

Additionally, we can store these unknown keys in a separate map on the Component

Pick a name for this for completeness sake.

$allow-unknown-keys$: true

Maybe the thing after colon can be type, so tomorrow we allow other types with easy?

[harshdoesdev]

We can call these additional_arguments

[amitu]

I am thinking we can handle these like we handle caption, body or children. We can call them kw-args.

-- component foo:
kw-args args:

-- end: foo

Like for caption, string is the default type. If you want to change type you can pass it explicitly:

-- component foo:
integer kw-args args:

-- end: foo

Here foo.args is hashmap of string to integer.

What about duplicates?

We should allow duplicates and handle them like Django's MultiValueDict.

[amitu]

@harshdoesdev move this discussion to a separate discussion. This is an independent feature.

[harshdoesdev]

Discussion continued: kw-args on components.