Вопрос по – Что НЕ должно быть модульным тестированием?

14

У меня сложилось впечатление, что некоторые проблемы состоят в том, чтобы сложно провести юнит-тестирование. И даже если вы делаете это, часто такие тесты дают мало пользы.

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

(может быть похож наэтот вопрос)

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

Ваш Ответ

6   ответов
2

но кроме этого, на самом деле нет ничего, что "не должно" быть. быть модульным испытанием.

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

0

е, поскольку компьютер не может решить, является ли то, что отображается на экране, правильным или нет! Хотя вы можете написать ручной тестовый модуль в этом случае, конечно

Я немного вводил в заблуждение, я имел в виду графику в реальном времени (то есть игры), которую было бы довольно сложно протестировать!
О, это определенно возможно для тестирования графического кода :) Такие инструменты, как AutomatedQA, имеют тесты со скриншотами, где можно сделать попиксельное сравнение между скриншотами. Хотя это определенно не стоит.
Артур спросил чтоshould не проверяться, не то, чтоcan не проверяться :)
@ Praveen - я бы сказал, стоит проверить графический код. Совсем недавно я работал над проектом, переводящим сложные графики в .pngs для доставки клиентам. Способность сравнивать сгенерированную контрольную сумму .png с эталоном НАМНОГО более надежна, чем визуальный осмотр, и пытаться вспомнить, что должно быть правильным.
3

automated тестирование функций и функциональности системы, но нетunit тестирование вообще:Следует ли тестировать внутреннюю реализацию или только тестировать публичное поведение?

Некоторые люди говорят, что единственной альтернативой юнит-тестированию является специальное ручное тестирование; но многие из преимуществ (например, регрессионное тестирование) связаны сautomated, а такжеnot обязательно от того, что он находится наunit уровень.

5

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

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

«Если этот код не стоит тестировать, почему его стоит иметь в первую очередь»? Если я использую язык, который заставляет меня иметь множество бесполезно повторяющихся шаблонов, то, возможно, мне не нужно тестировать эти части, если компилятор языка может просто проверить их; но я обычно использую языки, где код, который я пишу, действительно имеет смысл ;-).

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

Внедрение зависимостей позволяет вам использовать поддельный или фиктивный объект для обозначения (что бы ни "никогда не вызывало эту ошибку, но мы все равно ее исправляем" - сеть, база данных, интерфейс управления питанием и т. Д.), А также легко подделывать или издеваться может и определенно должно вызывать ложные ошибки всех видов, чтобы вы могли тщательно проверить этот код восстановления и диагностики.

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

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

Отличная точка зрения на ценность кода.
Хотя я считаю, что модульное тестирование полезно, время разработки - это дефицитный товар, и тестирование "всего" непомерно много времени. Я только говорю, что Frameworks должна получить покрытие, близкое к 100% (без учета шаблонов).
@ Алекс: Что, если для вас сгенерирован шаблонный код? Тогда вам не нужно было писать это, но это может не стоить модульного тестирования, если вы можете предположить, что генератор кода сделал это правильно.
Шаблон для вас может быть сгенерирован (я думаю о шаблонах кода через Eclipse), но тесты подтвердят: а) он был сгенерирован правильно, б) он не изменился. Если вы можете изменить способ генерации стандартного кода, есть место для ошибки, и кто может сказать, что кто-то не меняет код, созданный не членами команды. Это маленький анал? Может быть. Но я бы предпочел приложить усилия.
@Kevin, современные инструменты и подходы, а также хороший процесс объединяются, чтобы снизить затраты на тщательное тестирование, в то время как стоимость ошибок, обнаруженных позже, чем возможно, все еще может быть очень высокой. Таким образом, вам все еще нужно спросить: если этот код не стоит тестировать, почему его стоит писать? Если система должна иметь «шесть девяток»; Время работы, как он может позволить себе иметь менее шести девяток? охват тестированием - является ли это фреймворком или нет? -) Может быть, игры & amp; они разные (то есть, может быть, ошибки там очень дешевые, а время выхода на рынок имеет решающее значение) - я не знаю, я сам не являюсь разработчиком игр.
5

чем ближе вы пытаетесь достичь 100%, тем дороже это будет.

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

В зависимости от вашей ситуации вы можете отказаться от тестирования сквозных слоев и сгенерированного кода.

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

Похожие вопросы