-
Notifications
You must be signed in to change notification settings - Fork 135
Handle doubleton mutant filter in command line #434
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.
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
Handle doubleton mutant filter in command line #434
Conversation
On another project, I tried to pass two _separate_ mutant specs to mutmut run, and it promptly blew up with an assertion error, saying "Filtered for specific mutants, but nothing matches", _despite_ having successfully run each mutant spec on their own. Because that other project is quite large, I figured the best first step is to see if I can replicate the issue on mutmut's own test cases. Turns out I can. While I was at it, I also added tests for singleton mutant specs, both explicit and with wildcards.
As at the status quo, calling mutmut run with two or more mutant specs in quotes (such as "mutant_1 mutant_2") blew up with an AssertionError in collect_source_file_mutation_data, stating "Filtered for specific mutants, but nothing matches. ...." This commit handles that case, by splitting the tuple's element and replacing the tuple if the resulting split has 2 or more elements.
|
Shouldn't the command be ? I'd expect that to work given the current code. |
|
I'm not sure - I tried with both mutation specs in quotes - hmm... how about I try one spec out of quotes and two specs in quotes? |
|
The quotes has to do with how the shell interprets the commands, not how mutmut handles them. |
|
With the command line and passing That's somewhat unexpected - I was expecting either a detonation, or the full 21-mutant run |
Further discussion with @boxed revealed that I hadn't considered the case of a _multiple-element_ mutant_names tuple where at least one of the elements contains at least one space. First step, verify the wonkiness exists.
Second step, _fix_ the wonkiness and _verify_ the fix.
|
As at "Fix wonkiness when mutant names...", passing run PyRoute.TradeCodes.xǁTradeCodesǁcanonicalise__mutmut_1 "PyRoute.TradeCodes.xǁTradeCodesǁcanonicalise__mutmut_1? PyRoute.TradeCodes.xǁTradeCodesǁcanonicalise__mutmut_2?" to mutmut yields: |
|
I think the current mutmut behaviour was already correct, as long as you pass every filter as a separate argument, eg
Yes, you pass two arguments to the run command (you don't need to quote the first one because it has no spaces. Would be the same if you quoted it). The two filters result in the test selection you reported.
Here you only pass two arguments:
The first filter only has this single match. The second filter has no match (as it is accidentally a combination of two filters). |
|
Bollocks. Well, closing this PR then. |
Supplying two mutant specs to
mutmut runresulted in the following behaviour:This PR adds tests to verify that "Filtered for specific mutants..." issue exists on mutmut itself (it does), and adds a small, self-contained fix to teach mutmut to handle such multiple mutant specs.
After applying this PR, the same command line results in the following behaviour: