Add Math Mutations

[richardwerkman]

No description provided.

[hugo-vrijswijk]

These all look like C# math functions, I don't know if for example Java has the same methods. Perhaps it's cleanest to do a similar thing to method expressions and make a C# category for math methods?

[richardwerkman]

We can add the categories as soon as a second language support this right? Because for now C# is the only category

[hugo-vrijswijk]

Yes, but this now reads as though this should be the implementation for any language that wants to add math methods, while that's not the case. There should at least be some indication that this is C#-specific

[richardwerkman]

Done

[nicojs]

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

[richardwerkman]

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

[richardwerkman]

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

[nicojs]

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.

[richardwerkman]

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.

[nicojs]

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

[richardwerkman]

Done