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

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

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

(может быть похож на[этот вопрос](https://stackoverflow.com/questions/517977/what-do-you-test-with-your-unit-tests))

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

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

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

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

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



automated тестирование функций и функциональности системы, но нетunit тестирование вообще:[Следует ли тестировать внутреннюю реализацию или только тестировать публичное поведение?](https://stackoverflow.com/questions/856115)

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



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

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



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



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



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

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

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

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