Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Math Mutations #2233

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
+67 −0
Open

Add Math Mutations #2233

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
90e6543
Update supported-mutators.md
richardwerkman Dec 9, 2022
87699dd
update
Dec 9, 2022
705178d
prettier
Dec 9, 2022
aeb701f
update mutators
Dec 23, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions docs/supported-mutators.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,7 @@ All Stryker versions support a variety of different mutators. We've aligned on a
| [String Literal](#string-literal) | ✅ | ✅ | ✅ |
| [Unary Operator](#unary-operator) | ✅ | ✅ | ❌ |
| [Update Operator](#update-operator) | ✅ | ✅ | n/a |
| [Math Methods](#math-methods) | ❌ | ✅ | ❌ |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be a new mutator IMO. These are just Method Expression mutators, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well yes and no. We specifically check if the method is called on the Math class. If not we won't mutate. That's different from the other method mutators. We mutate those whatever they are called upon.

We could add these to the method expression mutators section. But then we should add Math. in front of all the mutations. And in Stryker.NET we already have them in a seperate section

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is something that should be able to turned off separately from the other method mutations.

Copy link
Member

@nicojs nicojs Dec 10, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is something that should be able to turned off separately from the other method mutations.

I can see that. That's why I think we should allow grouping a mutant operator outside of its category and individually name each mutant operator as per #1458 (I know the PR isn't sexy, but please take a look and provide feedback. It becomes more and more critical by the day).

However, that shouldn't be a reason to separate them here. It's still a method expression being mutated.

In the end, I think:

  1. Each mutant operator should have a unique mutation-testing-framework-agnostic name. For example: AcosMethodCallNegation
  2. Each mutant operator fits into exactly one category. For example: Method Expression
  3. Each mutant operator can fit into multiple groups. For example, based on level or class. For example @level1 or @mathMethods

We specifically check if the method is called on the Math class.

That is smart, but a tiny detail that shouldn't be steering the category naming scheme IMO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now I'd rather keep it like this. Since it has been merged already in Stryker.NET and would require a breaking change to revert. If in the future other strykers get math mutations as well we can realign.


## Arithmetic Operator

Expand Down Expand Up @@ -320,3 +321,61 @@ Strings and literals identified to a regex are mutated in the following way:
| `--a` | `++a` |

[🔝 Back to Top](#)

## Math Methods

> Currently only implemented for Stryker.NET. Future implementations for other languages can be implemented differently.

| Original | Mutated |
| -------------------------- | -------------------------- |
| `Acos()` | `Acosh()` |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're checking if this method comes from the Math class, shouldn't these be Math.Acos() -> Math.Acosh() ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

| `Acos()` | `Asin()` |
| `Acos()` | `Atan()` |
| `Acosh()` | `Acos()` |
| `Acosh()` | `Asinh()` |
| `Acosh()` | `Atanh()` |
| `Asin()` | `Asinh()` |
| `Asin()` | `Acos()` |
| `Asin()` | `Atan()` |
| `Asinh()` | `Asin()` |
| `Asinh()` | `Acosh()` |
| `Asinh()` | `Atanh()` |
| `Atan()` | `Atanh()` |
| `Atan()` | `Acos()` |
| `Atan()` | `Asin()` |
| `Atanh()` | `Atan()` |
| `Atanh()` | `Acosh()` |
| `Atanh()` | `Asinh()` |
| `BitDecrement()` | `BitIncrement()` |
| `BitIncrement()` | `BitDecrement()` |
| `Ceiling()` | `Floor()` |
| `Cos()` | `Cosh()` |
| `Cos()` | `Sin()` |
| `Cos()` | `Tan()` |
| `Cosh()` | `Cos()` |
| `Cosh()` | `Sinh()` |
| `Cosh()` | `Tanh()` |
| `Exp()` | `Log()` |
| `Floor()` | `Ceiling()` |
| `Log()` | `Exp()` |
| `Log()` | `Pow()` |
| `MaxMagnitude()` | `MinMagnitude()` |
| `MinMagnitude()` | `MaxMagnitude()` |
| `Pow()` | `Log()` |
| `ReciprocalEstimate()` | `ReciprocalSqrtEstimate()` |
| `ReciprocalSqrtEstimate()` | `ReciprocalEstimate()` |
| `ReciprocalSqrtEstimate()` | `Sqrt()` |
| `Sin()` | `Sinh()` |
| `Sin()` | `Cos()` |
| `Sin()` | `Tan()` |
| `Sinh()` | `Sin()` |
| `Sinh()` | `Cosh()` |
| `Sinh()` | `Tanh()` |
| `Tan()` | `Tanh()` |
| `Tan()` | `Cos()` |
| `Tan()` | `Sin()` |
| `Tanh()` | `Tan()` |
| `Tanh()` | `Cosh()` |
| `Tanh()` | `Sinh()` |

[🔝 Back to Top](#)