На днях пришлось долго отлаживать свою программу. В результате этого я задумался о важности тестов. Вдохновлённый протолжительностью отладки я скачал cppunit. После просмотра примеров у меня сложилось впечатление, что главное счастье от его использования — это умная директива ASSERT. В общем-то проверить, что 1=1 я и без этой программы мог. Очевидно, что я чего-то не понимаю.
Объясните мне, пожалуйста, в чём заключаются достоинства этой программы.
Заранее спасибо.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, товарищи!
А>На днях пришлось долго отлаживать свою программу. В результате этого я задумался о важности тестов. Вдохновлённый протолжительностью отладки я скачал cppunit. После просмотра примеров у меня сложилось впечатление, что главное счастье от его использования — это умная директива ASSERT. В общем-то проверить, что 1=1 я и без этой программы мог. Очевидно, что я чего-то не понимаю. А>Объясните мне, пожалуйста, в чём заключаются достоинства этой программы. А>Заранее спасибо.
Ты создаешь набор тестов, которые потом будешь прогонять автоматически, не задумываясь.
Или тебе охота каждый раз перед выпуском каждого релиза/патча вручную проверять, что в каждом модуле твоей программы по-прежнему 1==1 и ты ничего не сломал случайно?
You will always get what you always got
If you always do what you always did
Re[2]: Зачем нужен cppunit?
От:
Аноним
Дата:
20.09.05 16:32
Оценка:
Здравствуйте, jazzer, Вы писали:
J>Ты создаешь набор тестов, которые потом будешь прогонять автоматически, не задумываясь. J>Или тебе охота каждый раз перед выпуском каждого релиза/патча вручную проверять, что в каждом модуле твоей программы по-прежнему 1==1 и ты ничего не сломал случайно?
Предположим, у меня вся логика задачи сидит в отдельной библиотеке. Я создаю проект тестер и в нём создаю много тестов, для проверки которых мне достаточно выполить одну функцию TestAll. Всё это я напишу сам без cppunit. Так зачем мне его ставить?
Здравствуйте, Аноним, Вы писали:
J>>Ты создаешь набор тестов, которые потом будешь прогонять автоматически, не задумываясь. J>>Или тебе охота каждый раз перед выпуском каждого релиза/патча вручную проверять, что в каждом модуле твоей программы по-прежнему 1==1 и ты ничего не сломал случайно?
А>Предположим, у меня вся логика задачи сидит в отдельной библиотеке. Я создаю проект тестер и в нём создаю много тестов, для проверки которых мне достаточно выполить одну функцию TestAll. Всё это я напишу сам без cppunit. Так зачем мне его ставить?
Чтобы велосипед не изобретать.
cppunit — это фреймворк, который
— сам зарегистрирует все тесты, разбросанные по файлам тестового проекта
— не бабахнет на первом же ассерте, а аккуратно пробежит по всем тестам и расскажет, где, когда и с какими аргументами были assertion fault, а где были кинуты неожиданные исключения
— делает своё чёрное дело унифицированно; для командной работы это большой плюс.
Простота написания тестов позволяет нарожать их огромное количество.
За счёт этого можно найти и ошибки компиляции в том числе!
И разные эксперименты по рефакторингу проводить легко. Написал тест, поджёг, рвануло. Начинаешь думать — это ошибка в программе, или ошибка в твоём понимании программы. А почему она тогда возникла?..
Когда я с самоделок пересел на cppunit, то был поражён
Здравствуйте, dad, Вы писали:
dad>а как быть с классами которые только в контексте gui выполняются? (а протестить тоже хотелось бы)
Посмотри, может чего найдешь: http://opensourcetesting.org/
Там какой-то GUITAR был, но я не смотрел.
Хочется верить в чудо, но вряд ли GUI просто тестируется автоматически.
dad>>а как быть с классами которые только в контексте gui выполняются? (а протестить тоже хотелось бы) ГА>Посмотри, может чего найдешь: ГА>http://opensourcetesting.org/ ГА>Там какой-то GUITAR был, но я не смотрел. ГА>Хочется верить в чудо, но вряд ли GUI просто тестируется автоматически.
я там все смотрел, просто думал, может ты обладаешь откровением :)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
ГА>>Посмотри, может чего найдешь: ГА>>http://opensourcetesting.org/ dad>я там все смотрел, просто думал, может ты обладаешь откровением
Да где там, какие откровения
Я дальше Boost.Test (и простенького cxxunit, потому что Boost.Test на CE не работает) и не смотрел.
Здравствуйте, Глеб Алексеев, Вы писали:
К>>Когда я с самоделок пересел на cppunit, то был поражён ГА>С Boost.Test имеет смысл на cppunit переползать?
Когда искал себе unit-test-framework для С++ то выбирал между cppunit и Boost.Test. Остановился на Boost.Test, т.к.:
-- уж очень cppunit на JUnit похож. Boost.Test более C++like я бы сказал. Имхо, поэтому Boost.Test проще использовать (test-case легко можно делать обычными функциями, и так же легко использовать test-case в виде классов);
-- в Boost.Test больше вспомогательных макросов, что делает вставку ASSERT-ов гораздо читабельнее. Вот список boost-овских макросов из 1.32.0:
Здравствуйте, eao197, Вы писали:
E>Когда искал себе unit-test-framework для С++ то выбирал между cppunit и Boost.Test. Остановился на Boost.Test, т.к.: E>-- уж очень cppunit на JUnit похож.
А по мне, так это наоборот плюс. Потому как работать приходится много с чем, и наличие JUnit, CppUnit, NUnit не может не радовать.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
eao197 wrote:
> К>>Когда я с самоделок пересел на cppunit, то был поражён > ГА>С Boost.Test имеет смысл на cppunit переползать? > Когда искал себе unit-test-framework для С++ то выбирал между cppunit > и Boost.Test. Остановился на Boost.Test, т.к.: > -- уж очень cppunit на JUnit похож. Boost.Test более C++like я бы сказал.
Мне больше всего понравился TUT — очень простой и как раз сделаный
С++-like.
Здравствуйте, Кодт, Вы писали:
К>- сам зарегистрирует все тесты, разбросанные по файлам тестового проекта К>- не бабахнет на первом же ассерте, а аккуратно пробежит по всем тестам и расскажет, где, когда и с какими аргументами были assertion fault, а где были кинуты неожиданные исключения К>- делает своё чёрное дело унифицированно; для командной работы это большой плюс.
А как же Test First?
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Здравствуйте, kwas, Вы писали:
K>А как же Test First?
Думаю, все предыдущие рассуждения можно рассматривать в контексте <YouFavoriteUnitTestFramework> — акцент стоит не на cppunit, а на не самоделках, тыкскызыть.
ИМХО.
Здравствуйте, Alxndr, Вы писали:
K>>А как же Test First? A>Думаю, все предыдущие рассуждения можно рассматривать в контексте <YouFavoriteUnitTestFramework> — акцент стоит не на cppunit, а на не самоделках, тыкскызыть.
Меня, когда я увидел эту ветку, серьезно мучило желание спросить, а понимает ли вопрошающий что такое эти unit-тесты и для чего они используются. Но сдержался
Не, в принципе все верно, и даже в Test Infected описан такой подход: сначала что-то пишем, потом тестируем, если это что-то где-то ломается. Но, тут, как мне кажется, есть некоторая доля лукавства: код, приведенный в статье, один к одному совпадает с кодом, полученным с помощью Test Driven Development и описанным в книге Кента Бека. То есть, код, тестируемый в статье и преподносимый как Code Driven, на самом деле разработан с помощью TDD. Это и есть та доля лукавства, о которой я говорил (можно попытаться прикинуть и причины этого лукавства — например, популяризация). А вот следствия этого лукавства, как это часто бывает, идут далеко: как можно получить код, который легко тестировать? По-моему — только задумавшись об этом при написании кода. Людей, которые могут вот так, слету, написать красивый, расширяемый и легко поддающийся тестированию код я пока еще не встречал. Я бы такого человека назвал гением. Так их называет и Бек (не дословно): "TDD — для середняков. Гениям он не нужен, а тупицам — не поможет". Поэтому остается второй вариант — начинать собственно с тестов. Что в большинстве случаев и приводит к желаемым результатам.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Здравствуйте, kwas, Вы писали:
K>Людей, которые могут вот так, слету, написать красивый, расширяемый и легко поддающийся тестированию код я пока еще не встречал. Я бы такого человека назвал гением. Так их называет и Бек (не дословно): "TDD — для середняков. Гениям он не нужен, а тупицам — не поможет". Поэтому остается второй вариант — начинать собственно с тестов. Что в большинстве случаев и приводит к желаемым результатам.
Гений может легко по невнимательности облажаться — как в архитектурных вопросах, так и в банальном кодинге.
Здравствуйте, Кодт, Вы писали:
K>>Людей, которые могут вот так, слету, написать красивый, расширяемый и легко поддающийся тестированию код я пока еще не встречал. Я бы такого человека назвал гением. Так их называет и Бек (не дословно): "TDD — для середняков. Гениям он не нужен, а тупицам — не поможет". Поэтому остается второй вариант — начинать собственно с тестов. Что в большинстве случаев и приводит к желаемым результатам.
К>Гений может легко по невнимательности облажаться — как в архитектурных вопросах, так и в банальном кодинге.
+1
Так и хочется сказать: "Это точно. Вот помню один раз опечатался в коде..."
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> К>Гений может легко по невнимательности облажаться — как в > архитектурных вопросах, так и в банальном кодинге. > +1 > Так и хочется сказать: "Это точно. Вот помню один раз опечатался в > коде..."
Вспомнился анекдот:
Richard M. Stallman, Linus Torvalds, and Donald E. Knuth engage in a
discussion on whose impact on Computer Science was the greatest.
Stallman: "God told me I have programmed the best editor in the world!"
Torvalds: "Well, God told *me* that I have programmed the best operating
system in the world!"
Knuth: "Wait, wait — I never said that."
Здравствуйте, kwas, Вы писали:
K>>>А как же Test First? A>>Думаю, все предыдущие рассуждения можно рассматривать в контексте <YouFavoriteUnitTestFramework> — акцент стоит не на cppunit, а на не самоделках, тыкскызыть.
K>Меня, когда я увидел эту ветку, серьезно мучило желание спросить, а понимает ли вопрошающий что такое эти unit-тесты и для чего они используются. Но сдержался
А вот я как раз часто не понимаю... Имхо, unit-тесты хороши, когда есть какая-то библиотечка (той же сериализации, скажем) и нужно протестировать ее методы. Ну там сериализовать то-то, десериализовать, сравнить. Попробовать десериализовать то-то, посмотреть, что получилось. Это понятно. Это unit-тестами покрывается. Ну а дальше, когда библиотеки нужно в программу объединять? Вот есть у меня какой-нибудь агентик, который в каком-то состоянии на какое-то определенное воздействие определенным образом прореагировать должен. Причем агентик встраивается в какой-нибудь сложный фреймворк. Да и попадает в это состояние по сложной цепочке действий. И для моделирования всего этого приходится несколько процессов стартовать, определенные команды им выдавать. Вот в таких случаях чем пользоваться? Сейчас я специальные имитационные конфигурации делаю. Иногда вместо отдельных процессов специальные имитаторы пишутся. Но все запускается вручную. И проверяется так же вручную. Да и объем написаных unit-тестов оказывается настолько мал по сравнению с остальными работами. Ну т.е. не сказать, что совсем уж бесполезная штука (наоборот, свою задачу решает), но как бы это выразится -- мелкая по масштабу.
Все вышесказанное, естественно, ИМХО. Но интересно, что об этом другие участники форума думают.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Перекуём баги на фичи!
