Ловушки покрытия кода [закрываются]
Я пытался использовать метод, предложенный в ответах, но они не сработали в моем случае.
Решение:
Я попытался перевернуть createDrawerNavigator() с помощью createStackNavigator(), и это сработало идеально, как раньше! Мне не нужно использовать реагирующие навигационные события, нормальные события, такие как componentWillUnmount и componentWillMount, работают отлично.
const MainScreens = createStackNavigator(
{
Home: {screen: Home},
Post: {screen: Post},
Settings: {screen: Settings}
},
{
initialRouteName: "Home",
headerMode: "none",
}
);
const AppNavigator = createDrawerNavigator(
{
Main: {screen: MainScreens},
},
{
initialRouteName: "Main",
backBehavior: 'initialRoute',
contentOptions: {
activeTintColor: "#e91e63"
},
contentComponent: props => <SideBar {...props} />,
}
);
export default createAppContainer(AppNavigator);
Не уверен, что в том, что я сделал, что-то не так, но до сих пор оно работало нормально.
13 ответов
В предложении: покрытие Кода говорит Вам, что Вы определенно не протестировали, не, что Вы имеете.
Часть создания ценного комплекта модульного теста находит самый важный, рискованный код и задает трудные вопросы его. Вы хотите удостовериться жесткие работы материала как приоритет. У чисел покрытия нет понятия 'важности' кода, ни качества тестов.
По моему опыту, многие самые важные тесты, которые Вы будете когда-либо писать, являются тестами, которые едва добавляют любое покрытие вообще (пограничные случаи, которые добавляют некоторых дополнительный % тут и там, но находят загрузки ошибок).
Проблема с установкой трудных и (потенциально контрпродуктивных) целей покрытия состоит в том, что разработчикам, вероятно, придется начать наклоняться назад для тестирования их кода. Там делает код тестируемым, и затем существует только пытка. Если Вы поражаете 100%-е покрытие большими тестами затем, это фантастически, но в большинстве ситуаций дополнительное усилие просто не стоит того.
Кроме того, люди начинают преследовать/играть с числами вместо того, чтобы фокусироваться на качестве тестов. Я видел плохо записанные тесты, которые имеют 90 + покрытие %, так же, как я видел превосходные тесты, которые только имеют 60-70%-е покрытие.
Снова, я склонен смотреть на покрытие как на индикатор того, что определенно не было протестировано.
Просто, потому что существует покрытие кода, не означает, что Вы на самом деле тестируете все пути через функцию.
Например, этот код имеет четыре пути:
if (A) { ... } else { ... }
if (B) { ... } else { ... }
Однако всего два теста (например, один с A и B верный, один с A и ложью B) дали бы "100%-е покрытие кода".
Это - проблема, потому что тенденция состоит в том, чтобы прекратить тестировать, после того как Вы достигли волшебного 100%-го числа.
По моему опыту, самой большой проблемой с инструментами покрытия кода является риск, что кто-то падет жертвой веры, которые "высоко кодируют покрытие", равняется "хорошему тестированию". Большинство инструментов покрытия просто предлагает метрики покрытия оператора, в противоположность условию, каналу передачи данных или покрытию решения. Это означает, что возможно получить 100%-е покрытие на небольшом количестве кода как это:
for (int i = 0; i < MAX_RETRIES; ++i) {
if (someFunction() == MAGIC_NUMBER) {
break;
}
}
... никогда не тестируя условие завершения на для цикла.
Хуже, возможно получить очень высокое "покрытие" от теста, который просто вызывает Ваше приложение, не потрудившись проверять вывод, или проверяя его неправильно.
Проще говоря, низкие уровни покрытия кода являются, конечно, признаком недостаточного тестирования, но высокие уровни покрытия не являются признаком достаточного или корректного тестирования.
Иногда угловые случаи так редки, их не стоит тестировать, все же строгое правило покрытия кода требует, чтобы Вы протестировали его так или иначе.
Например, в Java алгоритм MD5 встроен, но технически возможно, что "неподдерживаемый алгоритм" исключение типа брошен. Это никогда не бросается, и Ваш тест должен был бы пройти значительные циркуляции для тестирования того пути.
Это была бы большая потраченная впустую работа.
По-моему, самая большая опасность, которой команда подвергается от имеющего размеры покрытия кода, состоит в том, что она вознаграждает большие тесты и штрафует маленькие. Если у Вас есть выбор между записью единственного теста, который покрывает значительную часть функциональности Вашего приложения и запись десяти маленьких тестов, которые тестируют отдельный метод, только измерение покрытия кода подразумевает, что необходимо записать большой тест.
Однако запись набора 10 маленьких тестов даст Вам намного менее хрупкие тесты и протестирует Ваше приложение намного более тщательно, чем один большой тест будет. Таким образом, путем измерения покрытия кода, особенно в организации с тихим развитием привычек тестирования, можно часто настраивать неправильные стимулы.
Я знаю, что это не прямой ответ на Ваш вопрос, но...
Любое тестирование, независимо от какой тип, недостаточно отдельно. Поблочное тестирование / покрытие кода для разработчиков. QA все еще должен протестировать систему в целом. Бизнес-пользователи все еще должны протестировать систему в целом также.
Обратное, QA тестирует код полностью, таким образом, разработчики не должны тестировать, одинаково плохо. Тестирование является дополнительным, и различные тесты обеспечивают разные вещи. Каждый тестовый тип может пропустить вещи, которые другой мог бы найти.
Точно так же, как остальная часть разработки не срезайте путь с тестированием, это только пропустит ошибки.
- Запись слишком целенаправленных тестовых сценариев.
- Недостаточное входное тестирование изменчивости Кода
- Большое количество искусственных тестовых сценариев выполняется.
- Не концентрируясь на важных отказах при испытании из-за шума.
- Трудность при присвоении дезертирует, потому что много условий от многих компонентов должны взаимодействовать, чтобы строка выполнилась.
Худший побочный эффект наличия 100%-й цели покрытия состоит в том, чтобы потратить большой цикл разработки тестирования (75% +) совершающие нападки угловые случаи. Другой плохой эффект такой политики является концентрацией удара конкретной строки кода вместо того, чтобы обратиться к диапазону исходных данных. Я действительно не забочусь, что функция strcpy работала, по крайней мере, однажды. Я действительно забочусь, что это работало против большого разнообразия входа. Наличие политики хорошо. Но наличие любой чрезвычайно драконовской политики плохо. 100%-я метрика покрытия кода не необходима и не достаточна, чтобы код считали основательным.
Одна из самых больших ловушек покрытия кода - то, что люди просто говорят о покрытии кода, на самом деле не указывая, о каком покрытии кода они говорят. Характеристики C0, C1, C2 и еще более высоких уровней покрытия кода очень отличаются, поэтому просто говорить о "покрытии кода" даже не имеет смысла.
Например, достижение 100%-го покрытия полного пути в значительной степени невозможно. Если Ваша программа имеет n моменты принятия решения, Вам нужно 2n тесты (и в зависимости от определения, каждый бит в значении является моментом принятия решения, так для достижения 100%-го покрытия полного пути для чрезвычайно простой функции, которая просто добавляет два ints, Вам нужны 18446744073709551616 тестов). Если у Вас только есть один цикл, Вам уже нужны бесконечно много тестов.
OTOH, достигая 100%-го покрытия C0 тривиален.
Другая важная вещь помнить, то, что покрытие кода не говорит Вам, какой код был протестирован. Это только говорит Вам, какой код был выполнен! Можно попробовать его сами: возьмите кодовую базу, которая имеет 100%-е покрытие кода. Удалите все утверждения из тестов. Теперь кодовая база все еще имеет 100%-е покрытие, но не тестирует единственную вещь! Так, покрытие кода не говорит Вам, что тестируется, только что не тестируется.
! 00%-е средство покрытия кода хорошо протестированный код является полным мифом. Как разработчики мы знаем твердые/сложные/тонкие части системы, и я очень видел бы те области, правильно протестированные, и только получил бы 50%-е покрытие, а не бессмысленное число, что каждая строка была выполнена, по крайней мере, однажды.
С точки зрения примера реального мира у единственной команды, что я был на этом, было 100%-е покрытие, написал часть худшего кода, который я когда-либо видел. 100%-е покрытие использовалось для замены обзора кода - результат был predicatably ужасен, до такой степени, что большая часть кода была выброшена, даже при том, что это прошло тесты.
Ничто неправильно с покрытием кода - что я вижу неправильно, не является 100%-м числом. В какой-то момент закон уменьшенных возвратов умирает, и становится более дорого протестировать последний 1%, чем другие 99%. Покрытие кода является достойной целью, но здравый смысл имеет большое значение.
100%-е покрытие кода не означает, что Вы сделаны с тестами usnit
function int divide(int a, int b) {
return a/b;
}
Со всего 1 модульным тестом я получаю 100%-е покрытие кода для этой функции:
return divide(4,2) == 2;
Теперь, никто не утверждал бы, что этот код единицы с 100%-м покрытием указывает, что он функция работает просто великолепно.
Я думаю, что покрытие кода является хорошим элементом, чтобы знать, пропускаете ли Вы какой-либо очевидный путь выполнения кода, но я использовал бы его тщательно.
Существуют инструменты там, Беспорядок для одного, которые выполняют анализ через покрытие ответвления путем видоизменения кода, чтобы видеть, перестал ли тест работать для всех различных перестановок.
Непосредственно с их веб-сайта:
Беспорядок является инструментом тестирования мутации уровня класса, который работает в сочетании с JUnit. Цель тестирования мутации состоит в том, чтобы обеспечить меру эффективности тестовых сценариев. Единственная мутация выполняется на коде, который будет протестирован, соответствующие тестовые сценарии затем выполняются. Если измененный код проваливает тесты, то это увеличивает уверенность в тестах. С другой стороны, если измененный код проходит тесты, это указывает на дефицит тестирования.
У нас есть хорошие инструменты для измерения покрытия кода от модульных тестов. Таким образом, заманчиво полагаться на покрытие кода 100% для представления этого, Вы "сделаны, тестируя". Это не верно.
Как другие люди упомянули, 100%-е покрытие кода не доказывает, что Вы протестировали соответственно, и при этом 50% не кодируют покрытие, обязательно означают, что Вы не протестировали соответственно.
Измерение строк кода, выполняемых тестами, является всего одной метрикой. Также необходимо протестировать на разумное множество входных параметров функции, и также как функция или класс ведут себя в зависимости от некоторого другого внешнего состояния. Например, некоторый код функционирует по-другому на основе данных в базе данных или в файле.
Я также недавно вел блог об этом: http://karwin.blogspot.com/2009/02/unit-test-coverage.html