Я должен записать модульный тест на все?

Я только пишу модульные тесты, где я знаю, что это экономит мне время. Когда я начал поблочное тестирование, это было только небольшим процентом классов (они ужасный ejb's!!). Сегодня я тестирую почти все, и я сохраняю общее время разработки на каждая вещь, которую я делаю . Если бы был эффективный способ протестировать ввод данных пользователем через микрофон, то я сделал бы это также. Но насколько я знаю, это не возможно способом, который экономит мне время.

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

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

Одно правило, которое я использую для решения, разработать ли модульные тесты: если Ваш класс (или безотносительно единицы) будет выпущенным "в дикую местность", затем необходимо определенно рассмотреть модульные тесты записи.

"в дикой природе", я имею в виду: после того как Ваш код будет в ситуации, где Вы не можете предсказать или управлять, как вещи будут взаимодействовать с ним. Таким образом, классы, выставленные через API или классы, выставленные вводу данных пользователем, должны, вероятно, быть протестированной единицей.

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

• , Насколько сложный класс? Очень простые классы не могло бы стоить тестировать.
• , Насколько очень важный класс? Код, работающий на ATM, надо надеяться, был бы протестированной единицей.
• , Сколько контроля Вы имеете над тем, как класс используется?

Затем всегда существует:

• , Когда крайний срок проекта?
• , Сколько рабочей силы Вы имеете посвященными созданию тестов?
• Ваш бетон требований и подробный, или класс все еще изменяется справедливо часто?

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

Короткий ответ, нет, но затем это идет для всего в программировании, когда Вы спрашиваете, "Должен я X для всего?"

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

Для больше на философской стороне см. это .

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

ответ на более общий вопрос да, Вы должны модульный тест все, что Вы можете. Выполнение так на потом создает наследие, таким образом, изменения в будущем могут быть сделаны с душевным спокойствием. Это гарантирует, что Ваш код работает как ожидалось. Это также документирует намеченное использование интерфейсов. Наконец, это вызывает лучший стиль кодирования. Обычно что-то, что твердо к модульному тесту, также плохо разработано. Запись для тестируемости означает писать для лучшего дизайна.

Другой пример: при разработке игрового механизма Вы хотите протестировать свое затенение и другие функции, но необходимо подтвердить это визуально - это - ничто, что классический UnitTest может решить.

Ваш Случай: , Поскольку Ваше приложение становится более сложным, это становится болезненным всегда для нажатия через UI для тестирования всех функций.

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

Вы могли бы хотеть проверить мою серию "Testing the Impossible" в мой блог для некоторых идей, как протестировать.

В Вашем случае, я предлагаю следовать идея Steve Rowe для записи теста, который настраивает динамик и микрофон, и используйте петлевой кабель для тестирования кода настройки оборудования плюс API, который позволяет испускать данные через динамик и считывать данные с микрометра.

Это - модульный тест, но не автоматизированный. Переместите его в независимый набор тестов, который не работает с другими автоматическими тестами. Если Вы хотите автоматизировать его, настройте второй ПК с корректной конфигурацией (плюс петлевой кабель) и запустите тест удаленно.

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

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

Однако, если Вы просто не пишете полученный звук в диск код, который вызывает Ваше получение и классы игры, конечно, может.

Два совета:

• не тестируют компилятор (например, метод считывания и метод set)
• Тест все, что могло возможно повредиться

Дешевый ответ: Тест все, что могло возможно повредиться

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

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

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

При направлении с трудностями, настраивающими конкретную область кода для тестирования могло бы стоить исследовать платформу насмешки как jMock, или EasyMock.

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

у меня был метод, который был 1 строкой долго. В подобных местах в моем приложении я записал модульные тесты, но спешение, я думал, что оно не могло возможно перестать работать. Я был неправ, это не работало :-)

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