LINUX.ORG.RU

Qt TDD

 , ,


1

2

Кто нибудь знает/принимал участие в проектах, где используется сабж?

Как удобней всего реализовать связь между основным проектом и прогоном тестов?

Какой тестовый фреймворк лучше использовать? Должен ли прогон тестов быть частью процесса сборки?

Вообщем как лучше организовать workflow, что бы было удобно работать, желательно используя QtCreator, при условии что так же планируется CI&


Не очень в курсе, что такое TTD, но есть опыт использования QtTest для разработки.

Опыт положительный, т.е. все получилось на ура, но тестировались только внутренние классы, без GUI.

Есть одна проблема, на написание тестов уходит куча времени и для большинства задач это лишний overhead.

trex6 ★★★★★ ()
Ответ на: комментарий от trex6

Не TTD а TDD(test driven developing). Просто юнит тесты без TDD вообще бессмыслено я думаю, проще приемочное тестирование выполнять:)

batbko ()

Юзаю гугловский фреймворк для юниттестирования. Помогает.

panter_dsd ★★★★ ()
Ответ на: комментарий от batbko

test driven developing

Вот его я как раз и практиковал. Для той задачи было необходимо, т.к. там файлы разбрасывались по дереву каталогов определенным образом и вручную тестировать это все (а подготовка дерева занимала до 5 минут) было бы просто глупо. Но для задач, не требующих такой длительной подготовки для каждого теста TDD может быть не самым быстрым средством для достижения цели.

trex6 ★★★★★ ()
Ответ на: комментарий от trex6

Это всё конечно круто и я рад за вас обоих, но основное что меня интересует - это пример workflow.

batbko ()

юзай cmake. make - сборка, make test - тестирование. И усе. Тесты кидай в отдельную директорию лучше и там же cmakelistst.txt

mio ★★ ()
Последнее исправление: mio (всего исправлений: 1)
Ответ на: комментарий от mio

Да, пока что CMake единственное что хоть как то напоминает нормальное окружение, но возможно есть примеры workflow с использованием qmake ?

batbko ()
Ответ на: комментарий от batbko

Зачем qmake, cmake лучше. Посмотри в примерах qt там есть наверняка.

mio ★★ ()
Ответ на: комментарий от mio

да просто странно, есть фреймворк, есть родная система сборки и родная система юнит тестов, но почему то все юзают что то другое :)

batbko ()
Ответ на: комментарий от batbko

да просто странно, есть фреймворк, есть родная система сборки и родная система юнит тестов, но почему то все юзают что то другое :)

Cmake вырос уже после qmake, и теперь считается, что он лучше. Но, так как выбрасывать старую систему было бы странно, qmake тоже существует.

anonymous ()
Ответ на: комментарий от batbko

есть фреймворк, есть родная система сборки и родная система юнит тестов

и внезапно этого вполне достаточно

на cmake советует переходить школоло, которое любит чем-то выделяться, по синтаксису и удобству использования cmake - отстой полный

anonymous ()
Ответ на: комментарий от anonymous

А ты попробуй с qmake вложенные подпроекты замутить. В свое время, 3 часа убил - не смог. На CMake замутил за пол часа.

panter_dsd ★★★★ ()
Ответ на: комментарий от trex6

test driven developing

Вот его я как раз и практиковал. Для той задачи было необходимо, т.к. там файлы разбрасывались по дереву каталогов определенным образом и вручную тестировать это все (а подготовка дерева занимала до 5 минут) было бы просто глупо. Но для задач, не требующих такой длительной подготовки для каждого теста TDD может быть не самым быстрым средством для достижения цели.

TDD - это не технология, а дисциплина. При следовании принципам TDD тоже используется в том числе и Unit-тестирование, но при этом постулируется написание тестов перед написанием кода.
Судя по описанию, Вы скорее всего подразумевали Unit-тестирование как инструмент автоматизации ручного труда.

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

Unit-тесты в любом случае должны быть. Вне зависимости от сложности тестирования.

Slavaz ★★★★★ ()
Ответ на: комментарий от Slavaz

Вы скорее всего подразумевали Unit-тестирование как инструмент автоматизации ручного труда

Нет. Все было в верном порядке: сначала тесты, потом стулья.

trex6 ★★★★★ ()
Ответ на: комментарий от trex6

Вообщем в качестве инструментов выбрали: Build & unit testing: qmake + gtest + gmock CI: jenkins + apache Bug & time tracking: jira SCM: git + gitlab SDE: scrum + tdd

batbko ()
Ответ на: комментарий от batbko

В итоге qmake всё таки заменили на cmake, т.к. добавилась ещё кросс компиляция, да и вообще cmake удобней как система сборки, хотя IDE его почему то поддерживают хуже

batbko ()
Ответ на: комментарий от batbko

В итоге qmake всё таки заменили на cmake, т.к. добавилась ещё кросс компиляция, да и вообще cmake удобней как система сборки, хотя IDE его почему то поддерживают хуже

KDevelop и QtCreator его нормально умеют.

unfo ★★★★★ ()
Ответ на: комментарий от unfo

QtCreator по сравнению с qmake никак не умеет, KDEvelop чуть лучше, но напирмер до sln в студии да и вообще нативных проектов в практически любом IDE как до луны :) Хотя с KDevelop я долго не игрался, мне криэтора хватает пока что.
Странно вообще столько любителей CMake и так мало контрибьютеров в плагины поддержки любимого тулчейна. Хотя вот я тоже нифига не могу время найти на то что бы поконтрибьютить :)

batbko ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.