Кстати, метрика построчного покрытия кода тестами часто вводит в заблуждение. Более лучшие метрики — это покрытие требований тестами, или покрытие тестами определенных моделей (классов) дефектов.
Может написать тесты на самые лютые методы? Например: GameStateLevel::ControlsToPhysics
GameStateLevel::PhysicsToGraphics
GameStateLevel::FireWeapon
GameStateLevel::ProcessSingleCollision
GameStateLevel::Update
Там очень много условий и ветвлений — навряд ли такое качественно тестируется вручную. Кроме этого: «It grown organically, so be prepared.» — будет расти, будет меняться, будут появляться регрессии. ;) Ну и в третьих, если эти алгоритмы рефакторить, то лучше это делать на тестах.
Ну а так вообще конечно нужен отзыв эксперта в написании игр. Как такой код отрефакторить к какой-то стандартной игровой архитектуре.
Нужно выстраивать систему мотивации, финансовой, карьерной, чтобы люди внедряли тесты. Например, не повышать до middle software engineer, пока программист не докажет на практике, что внедряет автоматические тесты.
Для рендера и UI могут подойти тесты, которые сравнивают результаты рендеринга (скриншоты) с эталонными с какой-то долей погрешности. Например, если кадр совпадает на 99% с эталонным, то все ок, если 95% — то все плохо.
Кроме этого на рендеринг наверняка performance тесты есть.
А вообще хороший подход — проанализировать какие ошибки вписываются на вашу игру, посмотреть из-за чего они происходят, попытаться обобщить и придумать тест, который покрывал бы такой класс ошибок.
Такое можно отслеживать с помощью business-level metrics, например, количество продаж в интернет-магазине, или если мы про пример Скайпа — это сколько звонков, чатов делается в месяц через него. Если поменяли дизайн и количество звонков выросло — это хороший дизайн. Если количество звонков упало — это провал.
Ну а так, да, например, Скайп меняет дизайн ежемесячно — я уже не то, что офигеваю, я просто не понимаю, куда нужно нажать, чтобы просто початиться с человеком. :)
Предположим, что релиз раз в месяц. Программист три недели писал код, затем тестировщик неделю тестировал, и в пятницу в 15:00, сообщил о 3 критических ошибках, 10 major и 20 minor. Общий эстимейт на исправление — 40 часов. А релиз версии был обещан в понедельник.
«Есть конкретные претензии? Назовите, обсудим это невыполненные требования или новые.»
Вот тут-то и самое интересное! Профессионал прислал работу, сказал: «Я все сделал», руководитель полез перепроверить, а там на 2 из 10 юз-кейсов приложение просто крешится. Говорить «я все сделал», когда на самом деле «я что-то там написал, но не проверял» — это непрофессионально и ненадежно.
«это возможно и без автоматических тестов, ручным тестированием»
Повторюсь, 500 тест-кейсов для мобильного приложения «Онлайн-кинотеатр» тестировщик проверяет за 40 рабочих часов для одной версии iOS, а поддерживаем мы их три. Автоматический тест смог бы проверить правильность за несколько часов.
И как вы себе представляете тестировать, например, копилятор языка в ручную без автоматических тестов?
Совершенно верно, не бинарное. В идеале, нужно разработать формулу, которая оценит систему, компонент или функцию в интервале от 0 до 1, где 1 — идеальная тестопригодность, 0 — полная нетестопригодность.
Например, идеальная тестопригодность у функции:
def sum(a, b):
return a + b
Потому что совершенно не нужно прикладывать никаких усилий, чтобы ее протестировать. :)
Я даже так скажу: отсутствие тестов — это любительский уровень программирования. Профессионал должен доказать руководству, заказчику, что его код работает корректно! А без автоматических тестов это сделать невозможно.
Вы плохо обо мне думаете, такого в статье я не писал!
«Нужен ведь не такой „энтузазист“, а специалист, который поможет внедрить малой кровью»
Перед тем как внедрять, нужно понять, почему это не было внедрено уже. Ведь в интернете есть кучу книг, статей и фреймворков — любой человек может скачать и внедрить. Но этого не происходит.
Врач, перед тем как лечить, проводит диагностику пациента, чтобы знать как и отчего лечить.
Если вы внимательно прочитаете эту отвратительную статью, то там для некоторых проблем даже наметки решения есть.
К сожалению, объем статьи не позволяет сразу и решение расписать. Это темы для будущих статей.
«нетестопригодные системы почему-то тестами не покрыты»
В проблеме сразу и отгадка: не покрыты, потому что нетестопригодны. :)
Из нашего опыта для нетестопригодных систем:
1. Расставляем функции по приоритету в соответствии с ценностью для клиента/пользователя.
2. Пишем высокоуровневые (UI или API) тесты.
Тем самым снижаем вероятность внесения случайных регрессий.
Знакомо! Однозначно проблема с культурой. Проблему культуры невозможно решить на уровне менеджмента, методов или технологий. Здесь только изменить (воспитать) правильную картину мира в голове.
«если срочных задач нет» — 99% срочных задач можно было бы избежать, если бы заранее было сделано надежно: проработаны требования, архитектура, сделан код ревью, написаны тесты. ;)
Еще я для себя вывел такое правило: если в текущем проекте написание тестов идет не как по маслу, то значит плохо с тестопригодностью. ;) Вы можете проверить это правило и на себе.
Подробнее я рассказываю в этом видео: youtu.be/t376yJuLncE
Если да, то тесты внедрены некорректно. Корректное внедрение повышает эффективность обнаружения ошибок.
Что значит «минимальная польза»? Т. е. они не обнаруживают никаких ошибок или регрессий?
Как-то оценивалось функциональное покрытие тестов?
GameStateLevel::ControlsToPhysics
GameStateLevel::PhysicsToGraphics
GameStateLevel::FireWeapon
GameStateLevel::ProcessSingleCollision
GameStateLevel::Update
Там очень много условий и ветвлений — навряд ли такое качественно тестируется вручную. Кроме этого: «It grown organically, so be prepared.» — будет расти, будет меняться, будут появляться регрессии. ;) Ну и в третьих, если эти алгоритмы рефакторить, то лучше это делать на тестах.
Ну а так вообще конечно нужен отзыв эксперта в написании игр. Как такой код отрефакторить к какой-то стандартной игровой архитектуре.
Если сотрудник приносит больше ценности компании, то и получать он будет пропорционально.
Нужно выстраивать систему мотивации, финансовой, карьерной, чтобы люди внедряли тесты. Например, не повышать до middle software engineer, пока программист не докажет на практике, что внедряет автоматические тесты.
Для рендера и UI могут подойти тесты, которые сравнивают результаты рендеринга (скриншоты) с эталонными с какой-то долей погрешности. Например, если кадр совпадает на 99% с эталонным, то все ок, если 95% — то все плохо.
Кроме этого на рендеринг наверняка performance тесты есть.
А вообще хороший подход — проанализировать какие ошибки вписываются на вашу игру, посмотреть из-за чего они происходят, попытаться обобщить и придумать тест, который покрывал бы такой класс ошибок.
Здесь большое поле для творчества.
Ну а так, да, например, Скайп меняет дизайн ежемесячно — я уже не то, что офигеваю, я просто не понимаю, куда нужно нажать, чтобы просто початиться с человеком. :)
Ваши действия? :)
Вот тут-то и самое интересное! Профессионал прислал работу, сказал: «Я все сделал», руководитель полез перепроверить, а там на 2 из 10 юз-кейсов приложение просто крешится. Говорить «я все сделал», когда на самом деле «я что-то там написал, но не проверял» — это непрофессионально и ненадежно.
«это возможно и без автоматических тестов, ручным тестированием»
Повторюсь, 500 тест-кейсов для мобильного приложения «Онлайн-кинотеатр» тестировщик проверяет за 40 рабочих часов для одной версии iOS, а поддерживаем мы их три. Автоматический тест смог бы проверить правильность за несколько часов.
И как вы себе представляете тестировать, например, копилятор языка в ручную без автоматических тестов?
Например, идеальная тестопригодность у функции:
Потому что совершенно не нужно прикладывать никаких усилий, чтобы ее протестировать. :)
«Нужен ведь не такой „энтузазист“, а специалист, который поможет внедрить малой кровью»
Перед тем как внедрять, нужно понять, почему это не было внедрено уже. Ведь в интернете есть кучу книг, статей и фреймворков — любой человек может скачать и внедрить. Но этого не происходит.
Врач, перед тем как лечить, проводит диагностику пациента, чтобы знать как и отчего лечить.
Если вы внимательно прочитаете эту отвратительную статью, то там для некоторых проблем даже наметки решения есть.
К сожалению, объем статьи не позволяет сразу и решение расписать. Это темы для будущих статей.
Если у вас уже есть решения — прошу, напишите!
В проблеме сразу и отгадка: не покрыты, потому что нетестопригодны. :)
Из нашего опыта для нетестопригодных систем:
1. Расставляем функции по приоритету в соответствии с ценностью для клиента/пользователя.
2. Пишем высокоуровневые (UI или API) тесты.
Тем самым снижаем вероятность внесения случайных регрессий.
Хоть какие-то тесты лучше полного отсутствия.
«если срочных задач нет» — 99% срочных задач можно было бы избежать, если бы заранее было сделано надежно: проработаны требования, архитектура, сделан код ревью, написаны тесты. ;)