Remove lines of codes, like method calls or List arguments

[passsy]

Thanks for creating this awesome tool! I used https://github.com/hcoles/pitest a lot in Java and I'm happy to see a similar tool for Dart. So far it is working, but the results are not very useful.

Remove method calls

The most common thing I detect with pitest is that method calls are not covered NonVoidMethodCallMutator. Look at this example:

void removeListener(void Function() listener) {
	_listeners.remove(listener);
}

I might call removeLister in my test, but I may not have a test that ensures the listener is removed from the internal list and won't fire anymore.

A mutation, removing the line would cover it:

void removeListener(void Function() listener) {
-   _listeners.remove(listener);
}

Remove list entries.

In my spot package, I create lists where each item is necessary. It would be beneficial to have a mutation that removes one entry.

  @useResult
  WidgetSelector<W> spot<W extends Widget>({
    List<WidgetSelector> parents = const [],
    List<WidgetSelector> children = const [],
  }) {
    final p = [if (self != null) self!, ...parents];
    final selector = WidgetSelector<W>(
      stages: [
        WidgetTypeFilter<W>(),
-       if (children.isNotEmpty) ChildFilter(children),
        if (p.isNotEmpty) ParentFilter(p),
      ],
    );
    return selector;
  }

---

Unfortunately, I think the XML Regex syntax is too limited for this kind of mutation. Do we maybe need a Dart API with granular control of the AST?

[domohuhn]

I agree that the regex syntax only allows simple mutations. Arbitrarily selecting mutants only in a certain context, like lists, is basically not possible (or at least it would very likely produce a significant amount of useless mutants).
However, adding a full parser for the Dart language and an API that allows adding fully custom mutations is a very large task, even if parsing the code is done by another package. The dart analyzer package provides an AST and could be used to improve this tool. But I would need to have a clear picture what kind of features you have in mind when using the AST.

The usefulness of certain mutants fully depends on your project. Some developers may specifically need the changes you suggested, but they may not be useful for everyone. There is pretty much an unlimited parameter space to check. I believe most people will simply stick to the default configuration, so providing a code extension that can arbitrarily manipulate the AST may be overengineered.
What's your vision regarding the API/new ways to add mutations? Do you want an additional DSL that can be used to arbitrarily create mutants? Or should there be a set of mutation passes that are defined in the code and that can be switched on and off via the configuration.

Removing the first and last entry in a list should be possible with the current implementation of the tool. Hitting an entry in the middle of list will be difficult. Removing method calls should be partially possible without adding a full-scale parser.
As a first step I can add additional rules based on your suggestions in this ticket, and check if they do not cause too many false positive matches.

[Levi-Lesches]

FWIW, I think removing void function calls can be useful. It's hard to miss calling a function that returns a value, because usually, that value is needed. Void functions (and functions whose return value isn't used) can be forgotten without invoking an analyzer error immediately, and therefore might go unnoticed. The only way to really notice them is if the function call uses a local variable that isn't used otherwise, because then you'll get an unused variable warning.

Without a complete AST-based overhaul, you might be able to just remove lines that call a function without saving the result (so basically. If that's too still too hard for regex, consider that many of these function calls tend to be one-liners. Like I mentioned above, if removing that call would result in an unused variable warning, it's a pretty useless mutation. You may be able to more quickly catch this false positive by analyzing the code instead of running the full test suite, and checking that the output has no warnings (or at least, no unused_local_variable warnings). This would still be a bit of overhead per mutation, but it's much less than running the full test suite.