Подсчет утверждений

В последнее время я получаю запросы от руководства на создание отчетов о количестве утверждений, выполненных тестами для нашего программного обеспечения. Они хотят этого, чтобы они могли сказать, пишут ли люди тесты или нет. Я склоняюсь к тому, чтобы просто сказать им: «Нет, вы не можете получить это, потому что вам это не нужно», но, похоже, это их не удовлетворяет.

Часть проблемы заключается в том, что наши команды пишут длинные тестовые примеры с большим количеством утверждений, и они хотят сказать, что протестировали какую-то новую функцию, потому что они добавили больше утверждений в существующий тестовый пример.

Итак, мой вопрос: есть ли у кого-нибудь хорошие, авторитетные (насколько это возможно) ресурсы, статьи или книги, хотя бы описывающие, как тестирование должно быть разделено на тестовые случаи или почему подсчет утверждений — это плохо?

Я имею в виду, что подсчет утверждений или утверждений на тест как измерение того, правы ли люди, тесты примерно так же полезны, как подсчет строк кода на тест. Но они просто не покупают это. Я пробовал искать в Google, но проблема в том, что никто не удосужился подсчитать утверждения, так что я не могу сказать "вот почему это плохая идея".


unit-testing xunit code-metrics tdd
person ZombieDev    schedule 13.02.2014    source источник
comment
Просто мое мнение: охват будет гораздо более полезной статистикой. Я мог бы написать тысячу утверждений и протестировать только одну строку кода.   -  person Carl Manaster    schedule 13.02.2014
comment
Конечно, и мы не измеряем покрытие в данный момент (мы хотели бы, но, не вдаваясь в подробности, язык, на котором написан код, делает это очень сложным). Я не ищу, чтобы покрытие было лучшей метрикой, а то, почему подсчет утверждений является плохой метрикой.   -  person ZombieDev    schedule 13.02.2014
comment
Коллега указал на эту страницу в документации junit, которую я почему-то пропустил при поиске: junit.sourceforge.net/doc/faq/faq.htm#tests_12 Я не уверен, что этого достаточно, чтобы считаться ответом на этот вопрос.   -  person ZombieDev    schedule 13.02.2014
comment
Почему бы не продемонстрировать тест через регулярные промежутки времени (конец спринта, перед выпуском, в конце месяца....), тогда они будут знать, пишете ли вы тест или нет. Но мне кажется, что микроуправление пошло не так. Их должно интересовать качество, а не инструмент (модульное тестирование), который вы используете для улучшения качества. Я могу порекомендовать практичные книги по модульному тестированию, которые можно найти на (pragprog.com).   -  person Jocke    schedule 17.02.2014
comment
Небольшое дальнейшее исследование проблемы показало, что внутренняя тестовая среда, которую написала команда, не останавливается на ошибочном утверждении, что является безумием. Это как бы объясняет, почему они пытаются втиснуть так много утверждений в один метод тестирования, потому что они не возражают, если некоторые из них потерпят неудачу, и считают, что они все еще что-то тестируют. Но эти тесты такие хрупкие, и когда один из них терпит неудачу, очень трудно сказать, почему. -_-   -  person ZombieDev    schedule 18.02.2014
comment
@Jocke, они делают какую-то демонстрацию в конце спринта, хотя я не уверен, что именно они демонстрируют, вероятно, не запуская свои тесты. Запрос исходил от их скрам-мастера (на самом деле больше похожего на менеджера проекта), который хотел что-то сообщить своему начальству. Он не мог сообщить, что они добавляли тестовые случаи, потому что у них было около 100 тестов (автоматизированных и зарегистрированных через Jenkins) в течение нескольких месяцев. Но разработчики говорят, что добавляют больше утверждений, поэтому менеджер хочет сообщить об этом. Я говорю, что не так тесты писать, он отвечает, мол кто?   -  person ZombieDev    schedule 18.02.2014
comment
@ZombieDev Хорошо, я слышу твою краску. Удачи!   -  person Jocke    schedule 18.02.2014

Ответы (4)


arrow_upward
2
arrow_downward

Воображение, позволяющее принимать глупые решения в управлении программным обеспечением, действительно не имеет границ, считая утверждения??... проблема с тестированием обычно связана с проблемой качества, а не с количеством.

Если вам нужна уважаемая ссылка, Gerard Meszaros xUnits выберет ее, пожалуй, одну из самых уважаемых, одну из рекомендаций «Проверить одно условие за тест» (http://books.google.es/books?id).=-izOiCEIABQC&lpg=PT111&ots=YIeYejY-mx&dq=meszaros%20one%20assertion%20per%20test&hl=es&pg=PT110#v=onepage&q=condition&f=false)

Но... если проблема заключается в том, что люди добавляют "новые тестовые сценарии", расширяя существующий тест "дополнительными утверждениями" вместо того, чтобы писать новый тест, лучшее, что может сделать ваша компания, - это купить много копий книги Месароса (и Кента использовать TDD на собственном примере и расширять объектно-ориентированный подход, руководствуясь тестами) и нанимать некоторых экспертов для обучения и руководства, пока не стало слишком поздно.

person AlfredoCasado    schedule 17.02.2014
comment
Я пока отмечу это как ответ, потому что мне нравится объяснение в той книге Google, на которую вы ссылались. Также вы упомянули Кента Бека, и люди здесь уважают его как авторитета в области TDD. В своей книге в середине страницы 125, говоря об изоляции тестов, он говорит: «Если бы у меня был сломан один тест, я хотел бы решить одну проблему. Подсчет утверждений на самом деле не является проблемой, проблема заключается в гигантских методах тестирования, вызванных простым добавлением дополнительных материалов (утверждений) в существующие тесты, а не созданием новых тестов. - person ZombieDev; 18.02.2014

arrow_upward
1
arrow_downward

Возможно, Agile Manifesto говорит об этом лучше всего:

Создавайте проекты вокруг мотивированных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.

Если вы попытаетесь запустить проект по метрикам, вы в конечном итоге получите все, что измеряете, например, множество утверждений, которые на самом деле не проверяют правильные вещи.

Или с более общей точки зрения управления: http://hbr.org/2010/06/column-you-are-what-you-measure/ar/1

person Mike Stockdale    schedule 14.02.2014

arrow_upward
1
arrow_downward

Книга Стива МакКоннела Code Complete охватывает код и тестирует аспекты качества, включая метрики, относящиеся к вашему делу.

Метрики должны стимулировать желательное поведение. В вашем случае желательное поведение — писать больше хороших тестов. Итак, попробуйте объяснить своим менеджерам, что подсчет утверждений не связан с желаемым поведением. На самом деле это может вызвать нежелательное поведение, упомянутое в другом ответе здесь.

Я согласен с пунктом из Agile Manifesto. Однако его можно успешно применять в здоровой окружающей среде. Я наблюдал случаи, когда некоторые инженеры отказывались писать юнит-тесты, потому что считали себя «успешными» без них последние 20 лет или около того. В этом случае не имеет значения, насколько вы доверяете им выполнение работы. Метрики меняют поведение. Они генерируют непредвзятые данные для лучшего принятия решений. Они полезны, но если это правильные показатели.

Удачи!

person Andrew    schedule 14.02.2014

arrow_upward
1
arrow_downward

Возможно, основной причиной этого является отсутствие видимости, вызванное длительными методами тестирования. На самом деле должно быть одно логическое утверждение, написанное для каждого теста (это может быть группа утверждений, но на самом деле их должно быть как можно меньше для проверки данного сценария), что-то большее, и тест становится менее читабельным, и кому-то труднее понять, что это на самом деле тестирование. Их также легче поддерживать, и их также будет легче изменить при изменении тестируемой системы. Длинные методы тестирования также имеют тенденцию быть очень хрупкими, поскольку они охватывают слишком большую часть поведения системы и могут потребовать изменения каждый раз, когда что-то меняется.

Я не могу найти пример навскидку, но есть несколько хороших ресурсов: Кент Бек и Марк Зееманн. Это очень актуально для этого вопроса.

Сами метрики всегда можно обмануть, вы можете получить 100% покрытие кода, с множеством утверждений и фактически ничего не тестировать, вы, вероятно, получите больше пользы, по крайней мере, на начальном этапе, от очистки тестов.

person gmn    schedule 17.02.2014
comment
Мне очень нравится идея, изложенная в этом вопрос наprogrammers.stackexchange.com, на который вы ссылались: тесты должны завершаться неудачно только по одной причине. Проблема в том, что эти тесты могут провалиться по... сотням причин. - person ZombieDev; 18.02.2014
comment
@ZombieDev Write Test со 100% покрытием кода и БЕЗ утверждений. Этот набор тестов навсегда останется зеленым. Если требования таковы, что тесты должны провалиться по одной причине, тогда у вас должно быть 100 тестов, 100 утверждений и 1 утверждение на тест. если у вас есть 100 тестов и только 20 тестов имеют утверждение, а 80 тестов не имеют, то я бы рекомендовал удалить 80 тестов, потому что качество кода и затраты на выполнение этих поддельных тестов равны нулю. - person Peter Ebelsberger; 25.07.2017