Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > IT форум > Общие вопросы по программированию, компьютерный форум
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 21.01.2014, 11:11   #1
8Observer8
Старожил
 
Аватар для 8Observer8
 
Регистрация: 02.01.2011
Сообщений: 3,322
Сообщение Юнит тесты, обсуждение

Чуть позже напишу, как создавать юнит тесты на Qt (это фреймворк для C++ разработчиков) Инструкция будет для начинающих Qt-разработчиков. Ссылку на инструкцию я дам в подписи. Ссылка будет называться: TDD Qt. Либо я объединю все инструкции в одну ссылку с названием: Пошаговые инструкции.

UPD:
http://www.programmersforum.ru/showthread.php?t=253582
http://www.programmersforum.ru/showthread.php?t=225824

Последний раз редактировалось Alex11223; 29.12.2016 в 20:54.
8Observer8 вне форума Ответить с цитированием
Старый 21.01.2014, 20:09   #2
rrrFer
Санитар
Старожил
 
Аватар для rrrFer
 
Регистрация: 04.10.2008
Сообщений: 2,618
По умолчанию

Цитата:
Чуть позже напишу, как создавать юнит тесты на Qt (это фреймворк для C++ разработчиков) Инструкция будет для начинающих Qt-разработчиков.
Буду ждать. Статей таких много (на хабре в том числе), но у меня больше вопросов чем ответов. Если можно, я сыпану тут пожеланиями.
0. грамотно отнестись к структуре статьи.
1. не брать избитые примеры, взять что-то более интересное
2. границы применимости юнит тестов и их правильное использование:
2.1. берешь книжки по TDD и читаешь, что тесты - панацея, однако...
2.2. если данных очень много (очень большие тесты)
2.3. если данные в файле
2.4. если данные в файле и могут размещаться в произвольном порядке
2.5. тестирование всякой математической лабуды (где числа сравниваются с заданной погрешностью {и погрешность можно считать как-нибудь хитро}) - из этого можно написать годный пример. Взять какой-нибудь метод решения уравнений, например
2.6. тестирование параллельного кода (это к границам применимости, скорее всего), я о случае, когда программа работает но в 0.1% случаев падает
2.7. что я еще забыл?

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

Я бы сделал акцент на красивых, ярких примерах и не абстрактных, а с полностью работающим кодом. При этом можно собрать кучу мелочей.

Ищешь ты корни квадратного уравнения/системы/кратчайший путь в графе и есть несколько возможных решений - что делать?

Ищешь ты кратчайший путь в графе, а там есть цикл отрицательного веса и процесс зацикливается? - тесты вообще завершатся? - сообщения на экране будут?

На выходе программа выдает какой-нибудь граф, сохраненный в файле. При этом порядок описания вершин не важен. Что делать?

Интересные вопросы можно поднять о тестировании ГУИ. Как тестировать тетрис, например. Или вот пишешь ты игру, и какой-то объект появляется на сцене не сразу, но надо проверить что он будет перемещаться корректно. Что делать? - я бы такие вещи вообще не тестировал, и когда читал о TDD - не мог понять как авторы себе это представляют.

Ну примерно такие, простые, всем понятные примеры. Которые можно было бы взять, скомпилировать и потыкать.

Я бы такую статью не написал, пришлось бы очень много работать.

Вообще, тесты на религию смахивают и тут холиварить можно тоже вечно. Например, если человек написал тесты - то может быть излишне уверен в правильности кода. Тут повсюду тонкие грани... ЗЫ. я тесты вообще почти не использую. Я пилю проекты, которые изначально разрабатывались без тестов мольшим количеством разработчиков, на разных языках и т.п. Я пробовал писать тесты, но часть проблем, приведенных выше, свела все усилия на нет. А так, как код пилит много народу, которые тесты не используют - то вообще не понятно в твоем коде ошибка или в их. Сколько тесты не пиши, результаты приходится брать и часами переваривать в голове самому. Образно, пишешь ты программу на некотором языке, но компилятор пишет другой человек. Твоя программа не работает в каком то частном случае, но чтобы проверить это - ты компилируешь программу компилятором, в корректности которого есть сомнения. Я понимаю, что проект должен быть покрыт тестами, и компилятор тоже, но это старый проект и все уже случилось иначе. Есть и другие похожие примеры.

Последний раз редактировалось Alex11223; 29.12.2016 в 20:54.
rrrFer вне форума Ответить с цитированием
Старый 21.01.2014, 21:23   #3
8Observer8
Старожил
 
Аватар для 8Observer8
 
Регистрация: 02.01.2011
Сообщений: 3,322
По умолчанию

rrrFer, я для начала написал пошаговую инструкцию для новичков в Qt (в подходе TDD): http://programmersforum.ru/showthread.php?t=253582

Потом буду рефакторить её, углубляться, расширять и т.д. Давай в ту тему перенесём обсуждение. Здесь тема литературы и не будем её засорять.

По поводу, нужны ли эти вещи из книг выше для больших проектов и больших команд разработчиков (я имею ввиду, рефакторинг, быстрая разработка, экстремальное программирование, TDD-модульные тесты, приёмочные тесты (и пользовательские сценарии) заказчика и т.д) Я даже нисколько не сомневаюсь, что нужны. Да, даже для маленького проекта и одиночки-фрилансера - тоже можно пользу извлечь. Хотя многие и без этого живут прекрасно и радуются жизни. Меня все эти вещи вдохновляют и я их с радостью использую даже в маленьких проектах.

Последний раз редактировалось 8Observer8; 21.01.2014 в 21:33.
8Observer8 вне форума Ответить с цитированием
Старый 22.01.2014, 09:10   #4
rrrFer
Санитар
Старожил
 
Аватар для rrrFer
 
Регистрация: 04.10.2008
Сообщений: 2,618
По умолчанию

8Observer8
Да, можно бы перенести. Но нужен модератор )).

Цитата:
Меня все эти вещи вдохновляют и я их с радостью использую даже в маленьких проектах.
Если проект на пару недель - то из тестов ИМХО много профиту не извлечешь.

Если крупный проект, но ты допиливаешь маленький его кусочек - то тесты тоже ИМХО не помогут. Ну вот последний проект - мне скинули 80.000 строк кода без тестов. Моя задача - за 2 недели доработать этот проект - у меня нет ни времени, ни возможности написать под это тесты.

Другой проект - изменение плагина графического редактора. Плагин нельзя протестировать без запуска редактора (беда?). Тестировать надо корректность изменений параметров изображения (и делать это надо визуально, а не как-то еще - еще одна беда?). И в этом же проекте, в идеале, надо тестировать то, что вывалит принтер (потому что плагин связан с высококачественной печатью). Я не понимаю как тут могут помочь тесты.

Другой пример - пишу я микроигрушку для ведра. Дак вот пока релизился Qt, игрушка странно себя вела на девайсе (точнее, странно работала анимация QPropertyAnimation). Если я запущу игрушку и посмотрю как там все это проигрывается - замучу косяки сразу. Но как мне в этом могут помочь тесты?
rrrFer вне форума Ответить с цитированием
Старый 22.01.2014, 10:45   #5
8Observer8
Старожил
 
Аватар для 8Observer8
 
Регистрация: 02.01.2011
Сообщений: 3,322
По умолчанию

rrrFer, я не буду тебе ничего доказывать. У меня нет времени на это.
8Observer8 вне форума Ответить с цитированием
Старый 22.01.2014, 11:16   #6
rrrFer
Санитар
Старожил
 
Аватар для rrrFer
 
Регистрация: 04.10.2008
Сообщений: 2,618
По умолчанию

Цитата:
rrrFer, я не буду тебе ничего доказывать. У меня нет времени на это.
да и не надо мне ничего доказывать. Ты сказал, что статьи хочешь написать, я предложил пару моментов, которые можно осветить в статье. Что и зачем ты доказываешь я понять не могу - не хочешь отражать мои предложения в статье - не отражай.
rrrFer вне форума Ответить с цитированием
Старый 07.06.2014, 17:15   #7
_Bers
Старожил
 
Регистрация: 16.12.2011
Сообщений: 2,329
По умолчанию

Цитата:
Сообщение от rrrFer Посмотреть сообщение
Если проект на пару недель - то из тестов ИМХО много профиту не извлечешь.
1. Тесты позволяют разработать более простой и практичный дизайн.

2. Можно потратить пару недель на конструирование, а потом ещё пару месяцев на правку багов.

А можно потратить пару недель на конструирование с тестами, и не тратить пару месяцев на правку багов.

Цитата:
Сообщение от rrrFer Посмотреть сообщение
Если крупный проект, но ты допиливаешь маленький его кусочек - то тесты тоже ИМХО не помогут.
Тесты провоцируют писать качественно структурированный код.
Поэтому, разработка крупного проекта, который строился с тестами представляет собой множество "маленьких кусочков, которые можно допиливать отдельно от остальной инфраструктуры проекта".

Это - одно из грандиозных положительных эффектов TDD.
Приводящее к ускорению разработки.

Цитата:
Сообщение от rrrFer Посмотреть сообщение
Ну вот последний проект - мне скинули 80.000 строк кода без тестов. Моя задача - за 2 недели доработать этот проект - у меня нет ни времени, ни возможности написать под это тесты.
Плохо структурированное имеющее множество зависимостей клюкало поздновато уже тестировать.

Разработка через тестирование предполагает использование тестов на все протяжении разработки с первого самого дня.

Существуют методики внедрения тестов на поздних этапах, но на мой взгляд они смахивают на костыли.

Хорошо структурированный код даже на поздних этапах хорошо поддается тестированию.




Цитата:
Сообщение от rrrFer Посмотреть сообщение
Другой проект - изменение плагина графического редактора. Плагин нельзя протестировать без запуска редактора (беда?).
Я не понимаю как тут могут помочь тесты.
Если действительно нельзя протестировать без запуска редактора - это уже говнокод в терминальной стадии. Только на выброс.

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

Цитата:
Сообщение от rrrFer Посмотреть сообщение
Другой пример - пишу я микроигрушку для ведра. Дак вот пока релизился Qt, игрушка странно себя вела на девайсе (точнее, странно работала анимация QPropertyAnimation). Если я запущу игрушку и посмотрю как там все это проигрывается - замучу косяки сразу. Но как мне в этом могут помочь тесты?
По чьей вине косяки то?
Вам необходимо понимание: что именно вы хотите тестировать?

Работоспособность самого QPropertyAnimation ?
Или корректность настроек, которые ему зарядил программист?

Вы можете покрыть тестами загрузчик картинок.
И сможете быть уверенным, что он правильно работает.

Но "красивость" самой картинки - это уже к художникам-фотошопперам.
Тесты это не вскроют, потому что они контролируют загрузчик, а не настройки конкретной картинки.
_Bers вне форума Ответить с цитированием
Старый 07.06.2014, 20:17   #8
rrrFer
Санитар
Старожил
 
Аватар для rrrFer
 
Регистрация: 04.10.2008
Сообщений: 2,618
По умолчанию

Цитата:
Но "красивость" самой картинки - это уже к художникам-фотошопперам.
Тесты это не вскроют, потому что они контролируют загрузчик, а не настройки конкретной картинки.
Не знаю писал я тут или нет, но пол года я участвовал в проекте, где косяки проявлялись на разных разрешениях монитора из за округления чисел. Короче была графическая сцена с картинками, у картинок были параметры в дробных числах (потому что во всяких опенглах вся графическая сцена располагается между нулем и единицей (никак не избежать дробноты координат). На конкретный монитор каждая картинка разжимается по своему и координаты округляются.
Баги выявляли тестеры-люди. Юнит тесты не сканают тут никак.

Суть в том, что юнит тесты тестируют модель, а не представление. В модели все может быть окей, а вот на деле... Не все можно протестировать, короче.

Цитата:
Но я что-то с таким не сталкивался.
В крайнем случае можно воссоздать фейковую среду за счет мок-объектов. Нужно лишь понимать принцип устройства и работы плагина.
Пишешь ты плагин для фотошопа или гимпа. Попробуй воссоздать фейковую среду.

Цитата:
Тесты провоцируют писать качественно структурированный код.
1) это не значит что без тестов качестенный код не пишется. Тесты провоцируют - может быть.
2) лично я щитаю,что в 99% случаев говнокод пишется тогда, когда заказчик говорит твоему работодателю "мне вчера нужен результат", работодатель говорит тебе - "если результата не будет завтра - не будет премии (а может и зарплаты, смотря на каких условиях работаешь)". Понятно что валить надо из такой конторы, но а если валить некуда? (и, например, на тебе висит кредит). В этом случае и пишется код, заворачивающий дерьмо в фантик. Случай утрированный, возможны разные варианты. Но суть одна, если на работу постоянно не дают время и угрожают всякими санкциями - получается говнод.
3) на тесты нужно время. Если твой работодатель поощряет тесты, то он дает время. Это значит что почти не бывает ситуаций из второго пункта. Поэтому и код получается качественный. Т.е. с тестами это связано косвенно (НО связано, я согласен). Если дать программистам время, то и без TDD с большой вероятностью код будет вменяемым и легкоподдерживаемый.

Цитата:
По чьей вине косяки то?
Вам необходимо понимание: что именно вы хотите тестировать?
Об том и речь, что если ты юзаешь альфа/бета-версии библиотек, то тесты могут валиться из за косяков в этих библиотеках, но ты то можешь это не знать и кучу времени убивать на поиски их в своем коде. Ну понятно что в рабочем проекте лучше их не использовать, но бывает что выхода нет же... - ты писал код на плюсах с Qt, а тут внезапно потребовалось портировать все на ведро/айфон/... (а вот версия библиотеки для айфона вдруг была еще сама в стадии тестирования...)

Последний раз редактировалось rrrFer; 07.06.2014 в 20:21.
rrrFer вне форума Ответить с цитированием
Старый 09.07.2014, 15:42   #9
_Bers
Старожил
 
Регистрация: 16.12.2011
Сообщений: 2,329
По умолчанию

Цитата:
Сообщение от rrrFer Посмотреть сообщение
Не знаю писал я тут или нет, но пол года я участвовал в проекте, где косяки проявлялись на разных разрешениях монитора из за округления чисел.
Баги выявляли тестеры-люди. Юнит тесты не сканают тут никак.

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

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

Цитата:
Сообщение от rrrFer Посмотреть сообщение
Пишешь ты плагин для фотошопа или гимпа. Попробуй воссоздать фейковую среду.
Я ж писал: "нужно лишь понимать принцип устройства и работы плагина".


Цитата:
Сообщение от rrrFer Посмотреть сообщение
1) это не значит что без тестов качестенный код не пишется. Тесты провоцируют - может быть.
Вопрос в цене жеж. С тестами разработка обходится дешевле.

Цитата:
Сообщение от rrrFer Посмотреть сообщение
2) лично я щитаю,что в 99% случаев говнокод пишется тогда...
Это "реальный код" по другому. Тот самый, что приносит компании прибыль. Так сказать реальность жизни.

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

Без тестов часто получается "прототип на выброс".

Цитата:
Сообщение от rrrFer Посмотреть сообщение
3) на тесты нужно время.
Суть идеи как раз таки в том, что с тестами код пишется быстрее, чем без них.

Вам не приходится тратить кучу времени на дизайн и архитектуру, и отладку.

Тесты естественным образом прямо на лету открывают перед вашим мысленным взором верное решение.



Цитата:
Сообщение от rrrFer Посмотреть сообщение
если ты юзаешь альфа/бета-версии библиотек, то тесты могут валиться из за косяков в этих библиотеках, но ты то можешь это не знать и кучу времени убивать на поиски их в своем коде.
Если вы используете глючное говно - никакие техники вам не помогут.
Вы в любом случае будите страдать, что с тестами, что без тестов.

Кстати, навеяло два случая на практике.

Первый - boost::filesystem, под форточками Junction Points заглючило.
Я делал обертку с блэк-джеком, а для того что бы шариться по диску использовал fs.

Ну так вот, тесты не просто обозначили сразу же проблему.
Практически моментально удалось точно установить, что косяк именно в fs, и более того - конкретную причину неисправности.

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

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

Таким образом получилось, что на гугл ушло больше времени, чем на поиски ошибки и отладку.


Другая ситуация - это GUI библиотека CEGUI.
Это тот случай, когда приходится страдать.
Ужассный дизайн, даже простые вещи делаются сложно, ля ля ля.

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

Помимо того, что решения приходилось искать чуть ли не методом научного тыка (вместо обычного здравого смысла), очень легко можно было что нибудь поломать-нарушить.

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

Нашел примерно с десяток косяков, все поправил.

И вот с тех пор CEGUI меня уже почти даже и не бесит. Только совсем изредка.

А вот без тестов таки и приходилось материться-маяться: что ни понос, то золотуха.
_Bers вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
юнит Вовик-вовик Помощь студентам 3 11.01.2012 02:10
ЮНИТ Вовик-вовик Помощь студентам 1 10.01.2012 23:30
юнит к на паскале Денис999 Помощь студентам 1 09.12.2010 13:41