This repository was archived by the owner on Sep 16, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 10
This repository was archived by the owner on Sep 16, 2021. It is now read-only.
Support additional test operators #13
Copy link
Copy link
Closed
Labels
help wantedExtra attention is neededExtra attention is neededquestionFurther information is requestedFurther information is requested
Description
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:
- Symbolic operators are difficult to search for
- Literal string equality checks are fragile
- String equality checks are inconvenient for complex values
- 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 patternerror
- 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 REPLassert: <swift code>
- runs the provided swift code as the next REPL statement; succeeds iftrue
is written to standard output; fails otherwise.
Finally, some open questions:
assert
can be used to implement any of the other checks (other thanerror
). 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
Labels
help wantedExtra attention is neededExtra attention is neededquestionFurther information is requestedFurther information is requested