Имеется большой и старый кросс-платформенный проект на с++, который заказчик хочет перевести на Юнит Тесты (автоматизированное тестирование). Сейчас тестирование в компании только ручное (собрали релиз — отдали тестерам). Код более или менее структурирован и разделен на модули, которые "теоретически" независимы. Приложение представляет из себя т.н. стэнд-элон аппликейшен для мобильных устройств со сложным динамическим гуём. С TDD сталкивался не раз, но всегда это было либо создание с нуля либо поддержание уже готового TDD проекта.
Интересует следующее (поделитесь опытом):
1. Как лучше начать перевод проекта под TDD (high-level)?
2. Какие подводные камни есть?
3. Инструментарий (использовал boost::test, но готов рассмотреть и что-то новенькое, т.к. изначально в проекте не используется boost).
4. Ссылки, статьи и прочие мануалы приветствуются.
Здравствуйте, szag, Вы писали:
S>Здравствуйте!
S>Имеется большой и старый кросс-платформенный проект на с++, который заказчик хочет перевести на Юнит Тесты (автоматизированное тестирование). Сейчас тестирование в компании только ручное (собрали релиз — отдали тестерам). Код более или менее структурирован и разделен на модули, которые "теоретически" независимы. Приложение представляет из себя т.н. стэнд-элон аппликейшен для мобильных устройств со сложным динамическим гуём. С TDD сталкивался не раз, но всегда это было либо создание с нуля либо поддержание уже готового TDD проекта.
S>Интересует следующее (поделитесь опытом): S>1. Как лучше начать перевод проекта под TDD (high-level)? S>2. Какие подводные камни есть? S>3. Инструментарий (использовал boost::test, но готов рассмотреть и что-то новенькое, т.к. изначально в проекте не используется boost). S>4. Ссылки, статьи и прочие мануалы приветствуются.
Сочувствую. Главный подводный камень — это "теоретическая" независимость. Если нет фактической независимости — нормальных юнит-тестов не будет.
Соответственно подход — пытаться все-таки выделить реально независимые модули ( или те, которые _реально_ легко сделать независимыми), пусть даже самые маленькие и примитивные, и написать тесты для них.
Для крупных и неразделяющихся кусков — только общее тестирование (пытаться выламывать куски из такого монолита — гиблое дело, проще с нуля переписать все), которое тоже может быть автоматизировано до какого-то предела, например — высунуть потроха наружу через boost.python и дальше написать кучу тестирующих сценариев на питоне.
привет!
изложу лишь некоторые, возможно, очевидные вещи.
во-первых, я не понял: требуется написать юнит-тесты к существующему коду или перейти на TDD? все же последнее является более емкой задачей и не применимо к существующему проекту. все же дизайн должен вырасти из тестов, а тестов нет, но дизайн есть. поэтому я склоняюсь к тому, что заказчику все же требуется написать юнит-тесту, дабы спалось спокойно и автоматически прогонялись тесты (не буду описывать плюсы и минусы всей этой кухни, тем более, что вы с TDD имели знакомство).
во-вторых, как бы вы не расписывали модульность и структурированность существующего проекта, я телепатирую о том, что проект покрыт толстым слоем говно-кода, ибо думать о грамотном разделении модулей, контроле зависимостей способен далеко не каждый, только если есть тиран и процесс, помогающий тирану заставлять всех об этом думать (например, обязательный код-ревью)
S>Интересует следующее (поделитесь опытом): S>1. Как лучше начать перевод проекта под TDD (high-level)?
вы попали в порочный круг: чтобы писать юнит-тесты, надо рефакторить, чтобы рефакторить-нужны юнит-тесты, которые исключили бы регрессию. так как их нет, то придется рефакторить и рисковать рефакторинг нужен, чтобы уменьшить зависимости, разрубить классы-боги, отделить мух от котлет
S>2. Какие подводные камни есть?
риски есть, что все сломается. поэтому нужно обеспечить себе быстрые проверки, что все пашет, как и раньше. либо под рукой иметь тестера, либо самому регулярно проводить ручное тестирование, дабы быть уверенным, что старые алгоритмы не сломаны. со временем, кол-во мануальных тестов будет уменьшаться, так как они будут переходить в зону автотестов. думаю, это сможет мотивировать бойца S>3. Инструментарий (использовал boost::test, но готов рассмотреть и что-то новенькое, т.к. изначально в проекте не используется boost).
тут, к сожалению, я неопытен, использовал CPPUNIT, сейчас сижу на tut. слышал, что всего две библиотечки заслуживают внимание: boost test, google test (там еще прилагается mock lib)
S>4. Ссылки, статьи и прочие мануалы приветствуются.
кроме гугла ничего посоветовать не могу
ну только если Фаулер, "Рефакторинг", чтобы понимать, какие элементарные трансформации с кодом имеет смысл делать
успехов
> Интересует следующее (поделитесь опытом): > 1. Как лучше начать перевод проекта под TDD (high-level)?
Ничего не надо никуда переводить. Надо просто писать юнит-тесты
и включать их прогон в билд-систему.
У вас есть какие-то модули, так ? Есть. Вот -- на каждый
модуль, лучше снизу вверх, пишите юнит-тесты, и добавляете
в билд-систему, чтобы они прогонялись при каждой сборке.
Собственно, и всё. При этом никакой кардинальной переделки
проекта-то нет, просто дописываются тесты, включаются
в сборку, а проект в это время идёт сам своей дорогой.
> 2. Какие подводные камни есть?
Писать тесты на неспецифицированные модули -- это почти что их
переписывать заново.
> 3. Инструментарий (использовал boost::test, но готов рассмотреть и что-то > новенькое, т.к. изначально в проекте не используется boost).
Это в общем -то всё равно. Лучше чтобы там были fixures, это
пожалуй обязательное требование, всё остальное -- очень зависит.
Здравствуйте, MasterZiv, Вы писали:
MZ>Ничего не надо никуда переводить. Надо просто писать юнит-тесты MZ>и включать их прогон в билд-систему.
MZ>У вас есть какие-то модули, так ? Есть. Вот -- на каждый MZ>модуль, лучше снизу вверх, пишите юнит-тесты, и добавляете MZ>в билд-систему, чтобы они прогонялись при каждой сборке.
По печальному опыту нескольких проектов, в которые добавлялись тесты по-живому, понятие "модуль" в них является иллюзией.
Обычно все зависит от всего, и поднять можно только все приложение целиком.
Написать нечто, чтоб загрузит единственный "модуль" чтоб его потестировать — лучше сразу удавиться.
Так что в таких случаях помогает только сквозное скриптование и потом тестирование этими скриптами реакции приложения на элементарные действия.
Но это не юнит-тесты, сам понимаешь.
On 26.07.2011 11:26, jazzer wrote:
> По печальному опыту нескольких проектов, в которые добавлялись тесты по-живому, > понятие "модуль" в них является иллюзией.
Так это к тестам не относится вообще. Это в принципе плохо и от этого в принципе
нужно избавляться. Т.е. если нет модулей, то жить вообще трудно, а не
только тесты писать трудно.
> Обычно все зависит от всего, и поднять можно только все приложение целиком. > Написать нечто, чтоб загрузит единственный "модуль" чтоб его потестировать — > лучше сразу удавиться.
Ну, можно и всё приложение поднимать, но тесты писать на кусок.
Я вон писал для MySQL-я юнит-тесты, добавляли спец. комманду-запрос
в парсер SQL-я, загружался MySQL с нашим движком, и из консоли
мы давали эту секретную комманду, оно выполняло наши можно сказать
Unit-тесты.
> Так что в таких случаях помогает только сквозное скриптование и потом > тестирование этими скриптами реакции приложения на элементарные действия. > Но это не юнит-тесты, сам понимаешь.
Ну, как сказать. Если оно проверяет КУСОК, то вполне себе юнит-тест.
Здравствуйте, MasterZiv, Вы писали:
MZ>On 26.07.2011 11:26, jazzer wrote:
>> По печальному опыту нескольких проектов, в которые добавлялись тесты по-живому, >> понятие "модуль" в них является иллюзией.
MZ>Так это к тестам не относится вообще. Это в принципе плохо и от этого в принципе MZ>нужно избавляться. Т.е. если нет модулей, то жить вообще трудно, а не MZ>только тесты писать трудно.
Кто ж спорит, конечно, плохо. Просто обычно оно так и бывает, если сразу юнит-тестов не писали.
Здравствуйте, MasterZiv, Вы писали:
MZ>On 26.07.2011 11:42, jazzer wrote:
>> Кто ж спорит, конечно, плохо. Просто обычно оно так и бывает, если сразу >> юнит-тестов не писали.
MZ>Да не связано это с юнит-тестами вообще никак. Либо голова есть, и об этом MZ>думают, либо нет, и не думают.
Не скажи. Я сам наталкивался несколько раз, когда пишешь прототип, все хорошо и логично, начинаешь писать к нему юнит-тест — и опаньки, оказывается, не заметил, как привнес левую зависимость. Приходится рефакторить, чтоб эту зависимость убрать, благо на этапе прототипа это быстро.
А в production-коде это совсем не быстро будет, если не сказать — невозможно зачастую.
Не, я, конечно, не исключаю, что у меня головы нет
Но юнит-тесты заставляют развязывать компоненты, в то время как во время кодирования, когда перед тобой стоит совершенно другая задача и ты думаешь о ее бизнес-смысле, как-то не до отслеживания зависимостей, особенно когда все компилится и работает и уже виден свет в конце тоннеля.
On 26.07.2011 14:07, jazzer wrote:
> Не скажи. Я сам наталкивался несколько раз, когда пишешь прототип, все хорошо и > логично, начинаешь писать к нему юнит-тест — и опаньки, оказывается, не заметил, > как привнес левую зависимость. Приходится рефакторить, чтоб эту зависимость > убрать, благо на этапе прототипа это быстро.
Ну это только потому, что написание юнит-теста -- это первый случай
обособленного использования этого компонента. Это мог бы быть запросто
и не юнит-тест, а что-то другое.
> А в production-коде это совсем не быстро будет, если не сказать — невозможно > зачастую. > Не, я, конечно, не исключаю, что у меня головы нет
26.07.2011 8:51, MasterZiv пишет: >> 1. Как лучше начать перевод проекта под TDD (high-level)? > > Ничего не надо никуда переводить. Надо просто писать юнит-тесты > и включать их прогон в билд-систему. > > У вас есть какие-то модули, так ? Есть. Вот -- на каждый > модуль, лучше снизу вверх, пишите юнит-тесты, и добавляете > в билд-систему, чтобы они прогонялись при каждой сборке.
А бы начинал сверху вниз. Так легче.
>> 2. Какие подводные камни есть? > > Писать тесты на неспецифицированные модули -- это почти что их > переписывать заново.
Ну можно воспринимать модуль как "черный ящик" (вход, выход,
управление). Понимание того, что некий модуль делает, надеюсь есть.
рефакторинг нужен, чтобы уменьшить зависимости, разрубить классы-боги, отделить мух от котлет
