|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
Опции темы | Поиск в этой теме |
21.01.2014, 11:11 | #1 |
Старожил
Регистрация: 02.01.2011
Сообщений: 3,327
|
Юнит тесты, обсуждение
Чуть позже напишу, как создавать юнит тесты на 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. |
21.01.2014, 20:09 | #2 | |
Санитар
Старожил
Регистрация: 04.10.2008
Сообщений: 2,577
|
Цитата:
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. |
|
21.01.2014, 21:23 | #3 |
Старожил
Регистрация: 02.01.2011
Сообщений: 3,327
|
rrrFer, я для начала написал пошаговую инструкцию для новичков в Qt (в подходе TDD): http://programmersforum.ru/showthread.php?t=253582
Потом буду рефакторить её, углубляться, расширять и т.д. Давай в ту тему перенесём обсуждение. Здесь тема литературы и не будем её засорять. По поводу, нужны ли эти вещи из книг выше для больших проектов и больших команд разработчиков (я имею ввиду, рефакторинг, быстрая разработка, экстремальное программирование, TDD-модульные тесты, приёмочные тесты (и пользовательские сценарии) заказчика и т.д) Я даже нисколько не сомневаюсь, что нужны. Да, даже для маленького проекта и одиночки-фрилансера - тоже можно пользу извлечь. Хотя многие и без этого живут прекрасно и радуются жизни. Меня все эти вещи вдохновляют и я их с радостью использую даже в маленьких проектах. Последний раз редактировалось 8Observer8; 21.01.2014 в 21:33. |
22.01.2014, 09:10 | #4 | |
Санитар
Старожил
Регистрация: 04.10.2008
Сообщений: 2,577
|
8Observer8
Да, можно бы перенести. Но нужен модератор )). Цитата:
Если крупный проект, но ты допиливаешь маленький его кусочек - то тесты тоже ИМХО не помогут. Ну вот последний проект - мне скинули 80.000 строк кода без тестов. Моя задача - за 2 недели доработать этот проект - у меня нет ни времени, ни возможности написать под это тесты. Другой проект - изменение плагина графического редактора. Плагин нельзя протестировать без запуска редактора (беда?). Тестировать надо корректность изменений параметров изображения (и делать это надо визуально, а не как-то еще - еще одна беда?). И в этом же проекте, в идеале, надо тестировать то, что вывалит принтер (потому что плагин связан с высококачественной печатью). Я не понимаю как тут могут помочь тесты. Другой пример - пишу я микроигрушку для ведра. Дак вот пока релизился Qt, игрушка странно себя вела на девайсе (точнее, странно работала анимация QPropertyAnimation). Если я запущу игрушку и посмотрю как там все это проигрывается - замучу косяки сразу. Но как мне в этом могут помочь тесты? |
|
22.01.2014, 10:45 | #5 |
Старожил
Регистрация: 02.01.2011
Сообщений: 3,327
|
rrrFer, я не буду тебе ничего доказывать. У меня нет времени на это.
|
22.01.2014, 11:16 | #6 | |
Санитар
Старожил
Регистрация: 04.10.2008
Сообщений: 2,577
|
Цитата:
|
|
07.06.2014, 17:15 | #7 | |||||
Старожил
Регистрация: 16.12.2011
Сообщений: 2,329
|
Цитата:
2. Можно потратить пару недель на конструирование, а потом ещё пару месяцев на правку багов. А можно потратить пару недель на конструирование с тестами, и не тратить пару месяцев на правку багов. Цитата:
Поэтому, разработка крупного проекта, который строился с тестами представляет собой множество "маленьких кусочков, которые можно допиливать отдельно от остальной инфраструктуры проекта". Это - одно из грандиозных положительных эффектов TDD. Приводящее к ускорению разработки. Цитата:
Разработка через тестирование предполагает использование тестов на все протяжении разработки с первого самого дня. Существуют методики внедрения тестов на поздних этапах, но на мой взгляд они смахивают на костыли. Хорошо структурированный код даже на поздних этапах хорошо поддается тестированию. Цитата:
Но я что-то с таким не сталкивался. В крайнем случае можно воссоздать фейковую среду за счет мок-объектов. Нужно лишь понимать принцип устройства и работы плагина. Цитата:
Вам необходимо понимание: что именно вы хотите тестировать? Работоспособность самого QPropertyAnimation ? Или корректность настроек, которые ему зарядил программист? Вы можете покрыть тестами загрузчик картинок. И сможете быть уверенным, что он правильно работает. Но "красивость" самой картинки - это уже к художникам-фотошопперам. Тесты это не вскроют, потому что они контролируют загрузчик, а не настройки конкретной картинки. |
|||||
07.06.2014, 20:17 | #8 | ||||
Санитар
Старожил
Регистрация: 04.10.2008
Сообщений: 2,577
|
Цитата:
Баги выявляли тестеры-люди. Юнит тесты не сканают тут никак. Суть в том, что юнит тесты тестируют модель, а не представление. В модели все может быть окей, а вот на деле... Не все можно протестировать, короче. Цитата:
Цитата:
2) лично я щитаю,что в 99% случаев говнокод пишется тогда, когда заказчик говорит твоему работодателю "мне вчера нужен результат", работодатель говорит тебе - "если результата не будет завтра - не будет премии (а может и зарплаты, смотря на каких условиях работаешь)". Понятно что валить надо из такой конторы, но а если валить некуда? (и, например, на тебе висит кредит). В этом случае и пишется код, заворачивающий дерьмо в фантик. Случай утрированный, возможны разные варианты. Но суть одна, если на работу постоянно не дают время и угрожают всякими санкциями - получается говнод. 3) на тесты нужно время. Если твой работодатель поощряет тесты, то он дает время. Это значит что почти не бывает ситуаций из второго пункта. Поэтому и код получается качественный. Т.е. с тестами это связано косвенно (НО связано, я согласен). Если дать программистам время, то и без TDD с большой вероятностью код будет вменяемым и легкоподдерживаемый. Цитата:
Последний раз редактировалось rrrFer; 07.06.2014 в 20:21. |
||||
09.07.2014, 15:42 | #9 | ||||
Старожил
Регистрация: 16.12.2011
Сообщений: 2,329
|
Цитата:
Именно тесты помогли отладить эту ошибку. Скажем так, изначально прошляпили, но когда обнаружили (обнаружили люди-тестеры), проблема была изучена и написаны тесты, которые гарантируют что теперь на любом разрешении косяков не будет. Цитата:
Цитата:
Это "реальный код" по другому. Тот самый, что приносит компании прибыль. Так сказать реальность жизни. Идеальный код не нужен. Нужен рабочий код, и как можно скорее. С тестами он пишется быстро, и при этом стабильно неплохое качество за такое время. Без тестов часто получается "прототип на выброс". Суть идеи как раз таки в том, что с тестами код пишется быстрее, чем без них. Вам не приходится тратить кучу времени на дизайн и архитектуру, и отладку. Тесты естественным образом прямо на лету открывают перед вашим мысленным взором верное решение. Цитата:
Вы в любом случае будите страдать, что с тестами, что без тестов. Кстати, навеяло два случая на практике. Первый - boost::filesystem, под форточками Junction Points заглючило. Я делал обертку с блэк-джеком, а для того что бы шариться по диску использовал fs. Ну так вот, тесты не просто обозначили сразу же проблему. Практически моментально удалось точно установить, что косяк именно в fs, и более того - конкретную причину неисправности. А все благодаря тому, что если код изначально пишется с тестами, то он пишется так, что легко и просто можно воссоздать любую ситуацию. Решение я нашел в течении нескольких часов. И собственно, благодаря тестам, удалось выполнить легкую хирургическую операцию ничего нигде не поломав, и не затронув ни дизайн, ни легаси. Таким образом получилось, что на гугл ушло больше времени, чем на поиски ошибки и отладку. Другая ситуация - это GUI библиотека CEGUI. Это тот случай, когда приходится страдать. Ужассный дизайн, даже простые вещи делаются сложно, ля ля ля. У него там очень много граблей. В зависимости от ситуации нечто может повести себя таким, или иным образом. Помимо того, что решения приходилось искать чуть ли не методом научного тыка (вместо обычного здравого смысла), очень легко можно было что нибудь поломать-нарушить. Я выявил наиболее "сомнительные" ситуативные моменты. Наклепал обертки с помощью которых можно было воссоздавать эти моменты. А потом покрыл обертки тестами. Нашел примерно с десяток косяков, все поправил. И вот с тех пор CEGUI меня уже почти даже и не бесит. Только совсем изредка. А вот без тестов таки и приходилось материться-маяться: что ни понос, то золотуха. |
||||
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
юнит | Вовик-вовик | Помощь студентам | 3 | 11.01.2012 02:10 |
ЮНИТ | Вовик-вовик | Помощь студентам | 1 | 10.01.2012 23:30 |
юнит к на паскале | Денис999 | Помощь студентам | 1 | 09.12.2010 13:41 |