Комментарии 14
А как бы вы порекомендовали тестировать работу с данными, точнее JDO?
In-memory database, не?
Ага, она самая. Я много лет не имел дела ни с чем, кроме связки Spring+Hibernate, поэтому слегка не в курсе, какие проблемы существуют за ее пределами, и могу только сказать, что dependency injection очень помогает с тестированием, в числе прочего. Т.е. позволяет легко подменить боевую базу на тестовую in-memory для тестов. А дальше задача сводится к предыдущей :)
Ну хорошо, а давайте вот-так: есть мультимедийное приложение, которое рисует разную графику, видюшки, картинки, анимацию и прочее в каких-то своих целях. При этом, ясное дело, такие вещи как 3-д движки, DirectX\OpenGL, видеокодеки, драйвера видеокарт и прочее не пишется с нуля, а используется уже готовое (и большинство — без исходников). И вот в зависимости от глюков всего вышеперечисленного, в определенных программно-аппаратных конфигурациях могут возникать глюки вида «вот эта линия недостаточно плавная» или «изображение слишком резкое» или «цвета как-то поплыли» или «тень от объекта падает не по вектору освещения». А ну как представьте мне способ написания тестов, проверяющих такие вещи.
Извините, не специалист в этом, поэтому даже не представляю, как подступиться. Первое, что приходит в голову — двигаться в лоб, т.е. сравнивать результат с эталоном. Подозреваю, что это смешное предложение :)
На самом деле, специалист именно в этой области должен спросить себя: что конкретно надо тестировать, какие данные подвергаются верификации? Какие части процесса находятся под моим контролем, и какие нет? То есть если упомянутые глюки заведомо являются глюками комбинации железа и драйвера, а мы пишем мультимедийное приложение, то можем ли мы что-нибудь с этим сделать, даже если найдем способ протестировать? Если же единственное, что мы можем сделать — это передать некоторые дополнительные параметры видео-драйверу, то и надо тестировать тот алгоритм, который передает эти параметры в зависимости от окружения, т.е., грубо говоря, assertNvidiaParametersSet(myAlgorithm(nvidia)), а не изобретать способы сравнения направления тени.
На самом деле, специалист именно в этой области должен спросить себя: что конкретно надо тестировать, какие данные подвергаются верификации? Какие части процесса находятся под моим контролем, и какие нет? То есть если упомянутые глюки заведомо являются глюками комбинации железа и драйвера, а мы пишем мультимедийное приложение, то можем ли мы что-нибудь с этим сделать, даже если найдем способ протестировать? Если же единственное, что мы можем сделать — это передать некоторые дополнительные параметры видео-драйверу, то и надо тестировать тот алгоритм, который передает эти параметры в зависимости от окружения, т.е., грубо говоря, assertNvidiaParametersSet(myAlgorithm(nvidia)), а не изобретать способы сравнения направления тени.
Сравнивать результат с эталоном — и вправду единственный хоть немного имеющий смысл вариант. Который по ряду причин часто не помогает:
-эталонной конфигурации для данной программно-аппаратной конфигурации просто нет, так как таких конфигураций до чёрта и для всех эталоны не создашь
-результат вообще никогда не совпадает с эталоном, поскольку на него влияет динамически-меняющиеся данные (рандом, время, действия юзера, картинка с камеры, информация из внешних источников и т.д.)
И да — я говорю именно о тех случаях, когда вся цепочка ДО взаимодействия с внешними компонентами проверена и я точно знаю, что параметры переданы верные. А что я могу с этим сделать — обматерить того, кто в реализации драйвера, кодека или движка слишком вольно подошел к трактовке стандарта и написать какой-нибудь «хак» для этой платформы, дабы его обойти. Например, видеокарты ATI некоторое время назад иногда весьма паршиво растягивали текстуры, размер которых не кратен числу 2, а NVidia вела себя корректно. Никакие, ну просто никакие тесты этого бы не поймали никогда.
Я конечно, не отрицаю нужность и важность тестов. Мне просто кажется, что иногда куча тестов служит оправданием нежеланию думать и разбираться в сути вещей в ходе ежедневной работы.
-эталонной конфигурации для данной программно-аппаратной конфигурации просто нет, так как таких конфигураций до чёрта и для всех эталоны не создашь
-результат вообще никогда не совпадает с эталоном, поскольку на него влияет динамически-меняющиеся данные (рандом, время, действия юзера, картинка с камеры, информация из внешних источников и т.д.)
И да — я говорю именно о тех случаях, когда вся цепочка ДО взаимодействия с внешними компонентами проверена и я точно знаю, что параметры переданы верные. А что я могу с этим сделать — обматерить того, кто в реализации драйвера, кодека или движка слишком вольно подошел к трактовке стандарта и написать какой-нибудь «хак» для этой платформы, дабы его обойти. Например, видеокарты ATI некоторое время назад иногда весьма паршиво растягивали текстуры, размер которых не кратен числу 2, а NVidia вела себя корректно. Никакие, ну просто никакие тесты этого бы не поймали никогда.
Я конечно, не отрицаю нужность и важность тестов. Мне просто кажется, что иногда куча тестов служит оправданием нежеланию думать и разбираться в сути вещей в ходе ежедневной работы.
Про все, кроме последнего абзаца: А что вы реально можете сделать? Ваш код работает правильно? Правильно. Параметры переданы верно? Верно. Добавление «хака» для какой-то платформы — это не починка бага, а новая фича по-любому. Тесты и не могут ее поймать, по определению. А уже для хака пишется отдельный тест, который, опять же, проверяет не картинку, то, что хак задействован на нужной платформе, и незадействован на ненужной.
Если проводить аналогию с близкой мне областью (веб-приложения), то ни один тест никогда не поймает тот факт, что цвет заголовка страницы вызывает понос у зам-директора. Когда этот факт станет известен, я добавлю себе новое задание: Не использовать цвета: красный, оранжевый и желтый, а то у замдира от них понос. И буду проверять, что ни один элемент в странице не будет использовать эти цвета. Но я никогда не подумаю вставлять замдиру беспроводной датчик поноса и интегриривать в свои тесты данные с оного.
А насчет последнего абзаца — это, вообще, о чем?
Если проводить аналогию с близкой мне областью (веб-приложения), то ни один тест никогда не поймает тот факт, что цвет заголовка страницы вызывает понос у зам-директора. Когда этот факт станет известен, я добавлю себе новое задание: Не использовать цвета: красный, оранжевый и желтый, а то у замдира от них понос. И буду проверять, что ни один элемент в странице не будет использовать эти цвета. Но я никогда не подумаю вставлять замдиру беспроводной датчик поноса и интегриривать в свои тесты данные с оного.
А насчет последнего абзаца — это, вообще, о чем?
Ну, или если без поноса, то как создатель веб-приложения я в принципе не могу отследить тот факт, что на некой комбинации ОС, браузера, и настройки шрифтов, шрифт заголовка рендерится криво. Ну нет такой возможности, ни у кого. Чтобы иметь возможность это заметить, люди должны смотреть глазами, и сообщать мне. Или пользователи, или же я могу посмотреть видео-запись моих автоматических веб-тестов. Не факт, что я замечу, но, предположим, что я заметил. И что мне с этим делать? Найти шрифт, работающий хорошо для этой комбинации, и написать тест, который проверит, что везде используется стандартный шрифт, а на этой комбинации внешнего окружения — специальный. И все. Я не тестирую браузеры и операционные системы (кроме случаев, когда я пишу браузер или операционную систему). Я могу тестировать только свой код. Мой код не занимается рендерингом, поэтому я рендеринг тестировать и не буду.
Создать реальную сцену из фанеры и пенопласта, полностью соответствующую игровой, раскрасить ее, сфотографировать и сохранить в .png
Затем пишите тест:
1. Установить камеру в нужную позицию на игровой сцене
2. Отрендерить и сохранить в .png
3. Сравнить отрендеренное изображение с полученным с фотокамеры )))
А вообще подобные проекты тестируется при помощи хомячков (ну или лемингов) )))
Затем пишите тест:
1. Установить камеру в нужную позицию на игровой сцене
2. Отрендерить и сохранить в .png
3. Сравнить отрендеренное изображение с полученным с фотокамеры )))
А вообще подобные проекты тестируется при помощи хомячков (ну или лемингов) )))
Ну, блин, фанера и пенопласт — я до такого не додумался :) Моя идея была проще — срендерить картинку на эталонном железе/драйвере, глазками посмотреть (а еще лучше, чтобы начальство глазками посмотрело и подписало), а потом сравнивать эту эталонную картинку с полученной в тесте. Подозреваю, что идиотская идея
Эталонное железо — это прекрасно. Я так думаю, из него сделана упряжка и подковы сферического коня в вакууме. Оно вечно, стабильно и надёжно. Вот только у конечного юзера его не будет, а будет какая-то хрень китайская по 5 баксов за пучок.
Еще раз: насчет эталонного сферического железа -это было в порядке бреда неспециалиста. Единственно правильный подход, как мне кажется, описан тут.
Что касается проблем в сторонних компонентах, то мы должны выловить все проблемы на компонентах, соответствующих некоторой спецификации. То, что конечный пользователь запустить на кривом железе и у него поплывет нас особо заботить не должно. Конечно, если таких пользователей много, то можно сделать work around, но опять же не стоит такие проблемы решить заранее.
>И самое главное, написание тестов — это не скучная обязанность, а просто правильный подход к написанию кода, который позволяет вам задумываться над по-настоящему интересными проблемами, а не над скучной рутиной.
Золотые слова :)
Золотые слова :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подход к тестированию кода в реальной жизни. Часть вторая