Add mutation for date operation

[boretti]

Is your feature request related to a problem? Please describe. It would be interesting to have mutation produced for operation on Date.

Expression like :

aDate.setDate(aDate.getDate()+1)

will produce interesting mutation based on the +1. It would also be interesting to have mutation changing the setDate or getDate operation (as updating month and not the day of month).

Describe the solution you'd like I propose to add the following mutation (to method-expression-mutator) :

• getDate to/from getMonth
• setDate to/from setMonth
• getHours to/from getMinutes
• setHours to/from setMinutes

Describe alternatives you've considered

Maybe other method are interesting to be mutated, but I think, a first set to start with is enough

Additional context

I will also create a PR with the proposal and link it with this Feature Request.

[nicojs]

This sounds like a great addition and is right in the spirit of what the method expression mutator is supposed to do. However, I don't see why we should stop at these four. For some use cases, people might be more interested in smaller or larger units of time.

This would be my suggestion.

From	To
Date.prototype.setDate()	Date.prototype.setTime()
Date.prototype.setFullYear()	Date.prototype.setMonth()
Date.prototype.setMonth()	Date.prototype.setFullYear()
Date.prototype.setHours()	Date.prototype.setMinutes()
Date.prototype.setMinutes()	Date.prototype.setHours()
Date.prototype.setSeconds()	Date.prototype.setMilliseconds()
Date.prototype.setMilliseconds()	Date.prototype.setSeconds()
Date.prototype.setTime()	Date.prototype.setDate()
Date.prototype.setUTCDate()	Date.prototype.setTime()
Date.prototype.setUTCFullYear()	Date.prototype.setUTCMonth()
Date.prototype.setUTCMonth()	Date.prototype.setUTCFullYear()
Date.prototype.setUTCHours()	Date.prototype.setUTCMinutes()
Date.prototype.setUTCMinutes()	Date.prototype.setUTCHours()
Date.prototype.setUTCSeconds()	Date.prototype.setUTCMilliseconds()
Date.prototype.setUTCMilliseconds()	Date.prototype.setUTCSeconds()

What do you think?

[boretti]

I think this is a good idea to have all these methods supported. I would also support both the get and the set version of the method.

[nicojs]

I'm personally less in favor of getxxx mutations. Could you provide an example where it would be useful and is not covered by a setXxx mutation?

[boretti]

I have the following example for get mutation, which are mostly business rules based on the date or the time :

• In Switzerland, the retirement age will change for the woman, in the next year, with rules like In 2025, the new reference age for woman born in 1961, will be 64 years and 3 months, in 2026, for woman born in 1962, it will be 64 year and 6 month, ... You will end up will rule only based on the get :

  if(currentDate.getFullYear() === 2025 && sex === 'F' && birthDate.getFullYear() === 1961) {
  // Retirement age is
  } else ...

• Another rule, an example for Switzerland, is that we must add a pay supplement when people work night or weekend. It may also require rules based on getHours() and getMinutes() to implements this logic.
• When you need to display date in some language, you may have requirements that, in French, the first day of the month is written "1er" (and in Italian, it may be 1°), but the next day are "only" 2, 3, ... ; Also in Italian, you may have to change how some word are written depending on the number following it.

[nicojs]

Thanks for the examples. I these particular examples are already tackled by the equality operator group of mutants, correct?

The problem with adding mutants for all methods is that they often overlap with other mutants that we already have. You probably call getHours() to calculate something or call setHours on another Date. The calculations are already covered by existing mutators. Your PR will cover the setHours.

Can you agree with this?

[boretti]

I see your point.

The equality operator should cover these case. I will update the PR according.