Как написать unit test и не надоедать в разработке проекта FOSS?

Я разрабатываю кросс-платформенный проект, который будет поддерживать:

Четыре компилятора С++ - GCC, MSVC, SunStudio, Intel,
Пять операционных систем: Linux, OpenSolaris, FreeBSD, Windows, Mac OS X.

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

Однако, как вы все знаете, написание модульных тестов крайне скучно и замедляет процесс разработки (потому что это скучно, и разработка программного обеспечения FOSS не должна быть такой)

Как вам удается написать хороший код модульного тестирования и не прекращать писать код.

Если вы хотя бы получите зарплату за это, вы можете сказать - по крайней мере, я что-то получу для этого, но если вы этого не сделаете, это намного сложнее!

Разъяснение:

Я понимаю, что TDD должен быть ключевым, но TDD имеет очень строгие ограничения:

У вас есть точные спецификации.
Вы полностью определили API.

Это справедливо для проекта, разработанного в стиле клиента-поставщика, но для проекта не может быть выполнено развивается.

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

Я вижу, что процесс развития больше похож на эволюцию, меньше развития в соответствии со спецификациями. Потому что, когда я начинаю внедрять какую-то функцию, иногда я не знаю, если это будет хорошо работать и какая модель будет использоваться.

Это совсем другой стиль разработки, который противоречит TDD.

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

Ответ 1

Лично я не нахожу тестирование скучным. Это первый раз, когда я вижу, что мой код запускается и выясняет, работает ли он или нет!

Без какой-либо формы тестовой программы для непосредственного запуска нового кода я бы не стал видеть, как он запускается до тех пор, пока я не построил пользовательский интерфейс и не соединил все это, чтобы сделать новые биты доступными через интерфейс, а затем, когда он не работает в первый раз, я должен попытаться отладить новый код, плюс пользовательский интерфейс, плюс клей, который держит их вместе, и дорогой бог, я даже не знаю, на каком слое есть ошибка, никогда ум, пытаясь определить фактический нарушительный код. И даже это предполагает, что я до сих пор помню, над чем я работал, прежде чем отправился на экскурсию в UI-land.

Собственная тестовая проводка обходит все это и позволяет мне просто называть новый код, локализовать любые ошибки в тестируемом разделе кода, чтобы их можно было быстро найти и легко устранить, увидеть, что он дает правильные результаты, получает мое "это" работает!" торопитесь и переходите к следующему фрагменту кода и моей следующей раздаче вознаграждения как можно быстрее.

Ответ 2

Я предлагаю сделать не unit test вообще. Поработайте немного над проектом и посмотрите, куда он ведет. Если вы не можете приложить достаточную мотивацию к тому, чтобы делать явно правильную вещь, тогда немного поработайте над своей проблемой, сделайте некоторые рефакторинг, исправление ошибок и несколько выпусков. Если вы затем увидите, какие проблемы всплывают, подумайте о TDD как о одном из возможных инструментов для решения.

Проблемы могут быть

низкое качество
высокая стоимость исправления ошибок.
нежелание рефакторинга (т.е. страх изменить существующий код)
субоптимальные API (API используются для позднего изменения)
высокая стоимость тестирования (т.е. мануальное тестирование)

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

TDD не является панацеей. Это может быть реализовано ужасно. Он не должен становиться флажком в вашем контрольном списке проектов.

Ответ 3

напишите им переход от модульных тестов к коду unit test в код... и т.д.

Ответ 4

Модульные тесты должны соответствовать всем наилучшим методам производственного кода, таким как принцип DRY. Если вам надоедают тесты на модульную запись, вам также будет скучно писать производственный код.

Test-Driven Development (TDD) может помочь вам, хотя вы постоянно переключаетесь между записью unit test, а затем немного производственного кода.

Ответ 5

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

Чтобы быть серьезным, если вы считаете, что письменные модульные тесты скучны и медленны, вам действительно нужно повторно обратиться к тому, как вы их пишете. Я предлагаю вам исследовать, используя Test Driven Development. Напишите тесты на языке программирования и запустите их автоматически. Используйте обратную связь от тестов, чтобы сформировать код.

Есть тесты First framework для практически любого языка, о котором вы хотели бы упомянуть, вдохновленного Кентом Бекем и Эрихом Гамма работать с JUnit. В статье Википедии о TDD есть дополнительная информация, включая полезную ссылку на список фреймворков, организованных языком. Узнайте больше.

Ответ 6

Как вам сказали другие люди: сначала писать тесты делает их забавными. Ваши заявления о том, что это невозможно сделать для развивающегося проекта, необходимо пересмотреть. На самом деле все наоборот. Если вы идете по гибкому маршруту, вам очень не рекомендуется определять все впереди. TDD вписывается в парадигму, что это невозможно и что изменения произойдут. Книга, которая делает это очень ясно, и дает примеры этого применение uml и шаблонов.

Ответ 7

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

В связи с характером проекта требуется достаточная степень автоматизации - найдите способ один раз написать тест для одного OS/компилятора, а затем запустите его для всех других доступных вариантов.