Operator Cheat Sheet

Operators in Testify are deliberately thin:

• they are fail-fast sugar over should
• they do not replace result
• they are best when they keep the test clearer than the named API

They are the surface syntax of the Testify DSL, not a separate engine. If you want the full model behind that statement, read DSL and Mental Model first or come back to it after this page.

If an operator stops being readable, switch back to the named API.

Assert Operators

Operator	Meaning	Named Equivalent	Returns	Best Used When
|>?	Apply one reusable expectation	Assert.should expectation expr	unit	You already have an expectation value
>>?	Apply one expectation and keep the quotation	Assert.should expectation expr plus chaining	the original quotation	You want left-to-right chained checks
=?	Equality assertion	Assert.should (AssertExpectation.equalTo value) expr	unit	Simple direct equality
<>?	Non-equality assertion	Assert.should (AssertExpectation.notEqualTo value) expr	unit	Simple direct inequality
<?	Less-than assertion	Assert.should (AssertExpectation.lessThan value) expr	unit	Simple comparison
<=?	Less-than-or-equal assertion	Assert.should (AssertExpectation.lessThanOrEqualTo value) expr	unit	Simple comparison
>?	Greater-than assertion	Assert.should (AssertExpectation.greaterThan value) expr	unit	Simple comparison
>=?	Greater-than-or-equal assertion	Assert.should (AssertExpectation.greaterThanOrEqualTo value) expr	unit	Simple comparison
^?	The quoted expression should throw	Assert.should AssertExpectation.throwsAny expr	unit	Exception-oriented tests
^!?	The quoted expression should not throw	Assert.should AssertExpectation.doesNotThrow expr	unit	Making exception-freedom explicit
?	Boolean expression should be true	Assert.should AssertExpectation.isTrue expr	unit	Short direct boolean tests
!?	Boolean expression should be false	Assert.should AssertExpectation.isFalse expr	unit	Short direct boolean tests
||?	Any expectation from a sequence may pass	Assert.should (AssertExpectation.any expectations) expr	unit	You have many alternatives
&&?	All expectations from a sequence must pass	Assert.should (AssertExpectation.all expectations) expr	unit	You have many required expectations

Check Operators

Operator	Meaning	Named Equivalent	Returns	Best Used When
|=>	Default fail-fast equality check against a reference	Check.should(CheckExpectation.equalToReference, reference, expr)	unit	The standard reference-style property test
|=>>	Same as |=>, but keep the quotation	Check.should(...) plus chaining	the original quotation	You want chain-friendly property syntax
|?>	Callback-built fail-fast property	Check.shouldBy(buildProperty, CheckExpectation.isTrue, (fun _ -> true), expr)	unit	You need custom quantification or dependent generation

Composition Operators

The composition operators are shared expectation-level building blocks.

Operator	Meaning	Named Equivalent	Notes
<|>	Logical OR of expectations	orElse	Chainable; use any for longer alternative lists
<&>	Logical AND of expectations	andAlso	Chainable; use all for longer required lists

Chainable Composition Examples

Short OR-chain:

let relaxedYes =
    AssertExpectation.equalTo "yes"
    <|> AssertExpectation.equalTo "y"
    <|> AssertExpectation.equalTo "true"

Short AND-chain:

let bounded =
    AssertExpectation.greaterThanOrEqualTo 0
    <&> AssertExpectation.lessThan 10
    <&> AssertExpectation.notEqualTo 7

On the property side:

let forgivingRelation =
    CheckExpectation.equalToReference
    <|> CheckExpectation.throwsSameExceptionType
    <|> CheckExpectation.equalByKey String.length 5

When To Prefer Named APIs

Prefer named APIs over operators when:

• you need result instead of fail-fast behavior
• the symbolic form hides too much meaning
• the property needs config or arbitrary
• the expectation deserves a meaningful name of its own

Operators are there to reduce ceremony, not to hide the structure of the test.