Skip to content
This repository was archived by the owner on Sep 16, 2021. It is now read-only.
This repository was archived by the owner on Sep 16, 2021. It is now read-only.

Support additional test operators #13

@mattt

Description

@mattt

For the initial proof of concept, I wanted to keep things simple with two operators:

  • => performs a string equality test on the standard output of the REPL
  • !! succeeds if the REPL writes anything to standard error

For a first take, this works pretty well. Assuming the REPL format remains relatively stable, this could work for a long time.

However, there are some drawbacks and limitations to the current approach:

  1. Symbolic operators are difficult to search for
  2. Literal string equality checks are fragile
  3. String equality checks are inconvenient for complex values
  4. String equality checks are incompatible with dynamic values (for example, relative date calculations, pointer addresses)

As an alternative, I'd like to propose a limited DSL / command syntax:

<swift code> // <command>[: <expression>]

Multiple expectations can be annotated for a single statement, either on subsequent lines or on the same line using /* block */ /* comments */

Here's a preliminary list of commands that I think we should support:

  • equals: <stdout content> - performs a string equality test on the content written to standard output by the REPL (equivalent to current =>)
  • matches: <regular expression pattern> - performs a regular expression test with the provided pattern
  • error - succeeds if the REPL writes anything to standard error (equivalent to current !!)
  • error: <stderr content> - performs a string equality test on the content written to standard error by the REPL
  • assert: <swift code> - runs the provided swift code as the next REPL statement; succeeds if true is written to standard output; fails otherwise.

Finally, some open questions:

  • assert can be used to implement any of the other checks (other than error). What's the cost/benefit for including them as well?
  • Should DocTest comments require a leading prefix to distinguish them from conventional comments (similar to how documentation comments use /** and ///)?
  • Should we deprecate the existing, symbolic operators, or designate them as aliases their new, corresponding commands? If we alias them, should we provide an alias for matches (~>)?

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is neededquestionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions