Crank - v0.11.1

Maintenance, Bug Fixes, Etc.

• Fixed bug preventing steps with multiple {{date(*)}} token instances from being replaced properly.
• Fixed a bug that could cause some {{date(*)}} token text to be misinterpreted.

Crank - v0.11.0

New in this Version

• Date Tokens - As of v0.11.0, Crank supports Date Tokens, which allow scenarios to be written with assertions and actions that contain date/times that are computed at Scenario Parse time. [#62]

---

The format of the date token is: {{date(*)}} where * can be a natural language string referring to dates/times in formats like the following:

• Specific Dates: {{date(January 1st, 2020)}}
• Relative Dates: {{date(1 day ago)}}
• With More Precision: {{date(30 minutes from now)}}

Contributors.

Thanks to @saludangelito for contributions to this release.

Crank - v0.10.2

Maintenance, Bug Fixes, Etc.

• Updated the cog:scaffold command so that it uses the latest, secure versions of dependencies

Crank - v0.10.1

Maintenance, Bug Fixes, Etc.

• Updated the cog:scaffold command so that it illustrates set and not set operators
• Added significant automated test coverage

Contributors.

Thanks to @amcpanaligan for contributions to this release.

Crank - v0.10.0

New in this Version

• Dynamic Tokens - As of v0.10.0, building on the extra metadata made available in v0.9.0, Crank supports Dynamic Tokens, which allow scenarios to be written with assertions and actions that depend on data that is only known at run-time. An example use-case is outlined below. [#43, #48]

Salesforce Object Assignment and Reference Precision

scenario: Salesforce Account Assign
description: Proves...

tokens:
  test.account: A Test Account
  test.email: [email protected]

steps:
# This step exposes the ID of the created Account as a token.
- step: Given I create a Salesforce Account
  data:
    account:
      Name: '{{test.account}}'
- step: And I create a Salesforce Contact
  data:
    contact:
      Email: '{{test.email}}'
      LastName: Tommy
      # Note: The ID can be used to assign the contact to the account. 
      AccountId: '{{salesforce.account.Id}}'
# The ID can be used to precisely target the object for field comparison
- step: Then the Name field on Salesforce Account with Id {{salesforce.account.Id}} should be {{test.account}}
- step: And the AccountId field on Salesforce Contact {{test.email}} should be {{salesforce.account.Id}}
- step: Finally, delete the {{test.email}} Salesforce Contact
# And it can be used to precisely target the object for deletion (no more ambiguity)
- step: And delete the Salesforce Account with Id {{salesforce.account.Id}}

Crank -v0.9.2

Bug Fixes, Etc.

• Fixed one more oustanding UX issue when running crank cog:step related to optional map fields [#45, #47]

Contributors.

Thanks to @saludangelito for contributions to this release.

Crank -v0.9.1

Bug Fixes, Etc.

• Fixed a UX issue when running crank cog:step related to optional fields [#45, #46]
• Updated dependent packages with known security vulnerabilities.

Contributors.

Thanks to @saludangelito for contributions to this release.

Crank - v0.9.0

New in this Version

• Run all consecutive validations - As of v0.9.0, the behavior when running Scenarios containing consecutive validation steps is different: if Crank encounters a fail or error response, but the next step is also a validation, it will continue until the next action step, or until the end of the scenario (whichever comes first). The outcome and exit code will remain the same (error or fail); this just ensures that all relevant failures are caught and logged in a single run. [#37, #38]
• Additional Step Output - As of v0.9.0, structured data will be printed on step fail or error (including tables and links to files) when available. If a Scenario is run with the --debug flag, every step will print this data. This is only true of Cogs that implement the cog.proto improvements introduced in this version.

API Additions

• Structured Response Data - A series of new message types and fields have been introduced, allowing steps to return structured data, in addition to the existing outcome, message format, and arguments. Cogs implementing this new version of the cog.proto can use these to return key/value data, table data, and binary data (e.g. images) to help crank users diagnose problems. [#28, #41]
• Step Context IDs - Three differently scoped contextual IDs have been added to the RunStepRequest message type. A request_id can be used to correlate consecutive steps, a scenario_id can be used to correlate steps across requests that belong to the same scenario run, and a requestor_id can be used to correlate steps across different scenario runs. Cogs implementing this new version of the cog.proto can use these as a basis for caching data and metadata to improve Cog performance. [#40]
• Field and Step Help Text - The FieldDefinition and StepDefinition message types now include help attributes. Cogs implementing this new version of the cog.proto can use these attributes to supply more detailed documentation. [#39]

All API improvements are reflected in the cog.proto documentation

Bug Fixes, Etc.

• Clearer Empty Message Args - In cases where a Cog returns a message argument that is an empty string, the empty argument will now be replaced with (empty value), to improve message readability and debugging [#33]
• Friendlier Lint Configs - Cogs scaffolded using crank cog:scaffold will use an updated lint configuration, reducing annoying lint errors and overrides [#35]

Contributors

Thanks to @saludangelito for contributions to this release.

Crank - v0.8.4

Bug Fixes, Etc.

• Fixed a bug in the cog:readme command that caused broken table formatting on GitHub when a step expression, or field description contained a | character [#31, #34]
• Fixed a bug in scaffolded Typescript code which caused generated code to not pass linting.
• Fixed a reference to a hard-coded Cog name in scaffolded Circle CI configs.

Contributors.

Thanks to @amcpanaligan for contributions to this release.

Crank - v0.8.3

Bug Fixes, Etc.

• Updated the cog:scaffold command to use @run-crank/utilities package in the example step for comparison. [#27, #32]
• Updated the cog:scaffold command to organize example step(s) in sub-folders and adopt the mixin approach for organizing client wrapper logic [#12, #32]

Contributors.

Thanks to @amcpanaligan for contributions to this release.