Как написать 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/компилятора, а затем запустите его для всех других доступных вариантов.