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
Some feedback that may be useful in future design decisions. I don't think this could be changed without a new major release which probably is not worth it.
The MatchOrElement uses a BitOr element to denote the separator. For the mutation testing library I contribute to, this is an unexpected overloading/reuse of the BitOr operator. At least in our usage, it would be better to have a different node class for this (e.g. MatchOrSeparator) to easily differentiate from the one used in expressions.
Previously, to create potential logic bugs, we replaced all operators with their opposite. So a = would be replaced with !=, + with -, etc. This seems to work well for everything now, except for the | to & mapping. The | to & mapping fails because it would map the match case case A() | B() to case A() & B() (which apparently gets rendered as case A()B() though I did not investigate this).
To fix this, I had to change the logic to only replace BitOr nodes within a BinaryOperation node. The change was not too big, so in our setup it was rather quick to fix this, but still unexpected behaviour to me.
I hope this feedback is helpful for you. The corresponding bug report at the repo: boxed/mutmut#402
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Some feedback that may be useful in future design decisions. I don't think this could be changed without a new major release which probably is not worth it.
The
MatchOrElement
uses aBitOr
element to denote the separator. For the mutation testing library I contribute to, this is an unexpected overloading/reuse of theBitOr
operator. At least in our usage, it would be better to have a different node class for this (e.g.MatchOrSeparator
) to easily differentiate from the one used in expressions.Previously, to create potential logic bugs, we replaced all operators with their opposite. So a
=
would be replaced with!=
,+
with-
, etc. This seems to work well for everything now, except for the|
to&
mapping. The|
to&
mapping fails because it would map the match casecase A() | B()
tocase A() & B()
(which apparently gets rendered ascase A()B()
though I did not investigate this).To fix this, I had to change the logic to only replace
BitOr
nodes within aBinaryOperation
node. The change was not too big, so in our setup it was rather quick to fix this, but still unexpected behaviour to me.I hope this feedback is helpful for you. The corresponding bug report at the repo: boxed/mutmut#402
Beta Was this translation helpful? Give feedback.
All reactions