You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
thank you for the reply @ikesyo. This still would be useful for our projects. With the change matcher, we can be assured that tests did not pass accidentally because the value was already matching expected. Also, it will help us writing tests without storing initial values in the variable that we have to name. Currently, we are writing preconditions for tests in "before each" block, which is less readable.
func change(_ subject:@autoclosure@escaping()->Int, by delta:Int)->Predicate<Void>{returnPredicate.define{ expr ->PredicateResultinletbefore=subject()try expr.evaluate()letafter=subject()letdiff= after - before
returnPredicateResult(
bool: diff == delta,
message:.expectedTo("change the subject by \(delta), but did change by \(diff)"))}}
Activity
ikesyo commentedon May 14, 2020
I'm sorry for the really late response but this looks interesting!
paulz commentedon May 14, 2020
thank you for the reply @ikesyo. This still would be useful for our projects. With the change matcher, we can be assured that tests did not pass accidentally because the value was already matching expected. Also, it will help us writing tests without storing initial values in the variable that we have to name. Currently, we are writing preconditions for tests in "before each" block, which is less readable.
ikesyo commentedon May 18, 2020
A very simple PoC:
paulz commentedon May 18, 2020
Love it!
and could that be even generic <T: Equatable> or Comparable?
ikesyo commentedon May 18, 2020
For
change(_:by:)matcherAdditiveArithmeticwould be appropriate to calculate a diff.Equatablecould be used forchange(_:from:to:)matcher.