Переключение делегирования не рассматривается в покрытии кода
При работе с корпусами переключателей я обнаружил следующую проблему. R# показал мне упрощение оператора switch, который в основном привязывает делегата к метке case, когда вы назначаете переменную.
var shape = shapeType switch
{
ShapeType.Ellipse => new Ellipse(),
ShapeType.Polygon => new Polygon(),
_ => new Rectangle()
};
Преимущество этого - удобочитаемость для огромных корпусов переключателей, потому что вы в основном экономите две трети строк для назначения переключателей.
Моя проблема: мне очень нравятся переключатели этого типа, поскольку они улучшают читаемость, но это не учитывается в средстве покрытия кода Visual Studio (VS Enterprise 2019 - 16.4.4). Поскольку наша политика направлена на покрытие кода примерно на 90%, каждый процент является ценным.
Есть ли возможность включить эти переключатели в покрытие кода?
1 ответ
Кейт в этом права. В моих проектах порог покрытия кода составляет жесткие 100%, и выражения переключения никогда не покрываются полностью, даже если эквивалентный оператор переключения.
Вот пример:
Следующий оператор switch обеспечивает 100% покрытия кода в моем проекте:
switch (values[3])
{
case "F": return new string(Convert.ToString(value, 2).Reverse().ToArray()).PadRight(max, '0');
case "G": return $"{value} of {max}";
case "R" when value == 0: return $"none of {max}";
case "R" when value == 1: return $"1st of {max}";
case "R" when value == 2: return $"2nd of {max}";
case "R" when value == 3: return $"3rd of {max}";
default: return $"{value}th of {max}";
}
Эквивалентное выражение switch дает только 99,91%, и сборка на Jenkins терпит неудачу:
return values[3] switch
{
"F" => new string(Convert.ToString(value, 2).Reverse().ToArray()).PadRight(max, '0'),
"G" => $"{value} of {max}",
"R" when value == 0 => $"none of {max}",
"R" when value == 1 => $"1st of {max}",
"R" when value == 2 => $"2nd of {max}",
"R" when value == 3 => $"3rd of {max}",
_ => $"{value}th of {max}"
};
И цвет покрытия кода не указывает, какая ветвь не покрывается, поскольку он отмечает весь оператор.
Я думаю, что это проблема того, как компилятор создает окончательный IL выражения. Ее следует рассматривать как ошибку C# и отправлять в Microsoft для исправления.