ZIO Test: Upgrade AssertResult to BoolAlgebra #1582
Conversation
|
Thanks! Yeah, I think there is even more we can do but wanted to take it one step at a time. |
| * a failure. | ||
| */ | ||
| final def failures: Option[BoolAlgebra[A]] = | ||
| fold[Either[BoolAlgebra[A], BoolAlgebra[A]]](a => Right(success(a)))( |
There was a problem hiding this comment.
Do you need to go through Either here?
There was a problem hiding this comment.
I think we do to deal with the not case. If we don't use Either then notCase turns Some into None, but what does it do with None? We've lost information by only using the option so for example if we had not(not(a)) we could't recover the original value, whereas a.swap.swap == a. Open to more elegant ways for achieving that but I think we definitely need some intermediate structure and Either seems to work relatively well.
| * the specified collection. | ||
| */ | ||
| final def all[A](as: Iterable[BoolAlgebra[A]]): Option[BoolAlgebra[A]] = | ||
| if (as.isEmpty) None else Some(as.reduce(_ && _)) |
There was a problem hiding this comment.
I think the empty case does not disprove the assumption, so should be true by default.
| * the specified collection. | ||
| */ | ||
| final def any[A](as: Iterable[BoolAlgebra[A]]): Option[BoolAlgebra[A]] = | ||
| if (as.isEmpty) None else Some(as.reduce(_ || _)) |
There was a problem hiding this comment.
same here, there is nothing to prove so the empty case is failure.
There was a problem hiding this comment.
ha, same thing as before, you need an A for the failure. ok scratch that then.
There was a problem hiding this comment.
if I'm correct, it's not strictly a bool algebra though, as there should be one and only one "false" element.
There was a problem hiding this comment.
Yeah, I'm definitely not an expert on this. I think in boolean algebra as a branch of mathematics there is only one true and one false element. I was more trying to go for the idea that it is a reification, an "algebra", of boolean operations. I'm not committed to the name though not sure about a better one. Any ideas?
There was a problem hiding this comment.
oooh yeah, that makes sense. I don't have a better proposition either way 😆
|
Yeah, I agree with you about the name. What about type AssertResult = BoolAlgebra[AssertionValue]
type TestResult = BoolAlgebra[FailureDetails]So maybe this is a general "result" type that can be instantiated with specific types of result data. That is already very consistent with the Scaladoc I have now. |
|
@jdegoes Any other thoughts on names for this? Would be nice to get it merged so we can start building on it. |
|
@adamgfraser can you solve the conflict? Also, let's merge it and rename it later if we find a better name? |
|
@ghostdogpr I just solved the conflict. Agree. |
Following up on discussions in #1438 this upgrades
AssertResulttoBoolAlgebraby adding aNotsubtype to the algebraic data type. This lets us clean things up a lot because we don't need anEitherembedded within it anymore to represent failure. It also allows us to preserve all information as we combine different assertions and implement all logical operations on assertion results including negation and more complex operators like implication, though that is not implemented here. We may want to rethink some of the other backend supporting data structures based on this but I think this is already a big enough PR. No significant changes to the API for users.