Тесты, которые в 2-3 раза больше тестируемого кода

Question

Нормально ли иметь тесты, которые намного больше, чем реальный тестируемый код? Для каждой строки кода, которую я тестирую, у меня обычно есть 2-3 строки в модульном тесте. Что в конечном итоге приводит к тому, что тратится огромное количество времени, просто набирая тесты (издевайся, смейся и смейся больше).

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

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

Answer 1

Да, это нормально. Это не проблема, что ваш тестовый код длиннее, чем производственный код.

Возможно, ваш тестовый код может быть короче, чем он есть, а может и нет, но в любом случае вы не хотите, чтобы тестовый код был «умным», и я бы сказал, что после первого написания вы не Я не хочу реорганизовать тестовый код, чтобы сделать что-то общее, за исключением случаев, когда это абсолютно необходимо. Например, если у вас есть регрессионный тест для прошлой ошибки, то, если вы не измените тестируемый публичный интерфейс, не трогайте этот тестовый код. Когда-либо. Если вы это сделаете, вам нужно будет только вытащить какую-то древнюю версию реализации, до исправления ошибки, чтобы доказать, что новый регрессионный тест все еще работает. Пустая трата времени. Если единственный раз, когда вы модифицируете свой код, это сделать его «проще в обслуживании», вы просто создаете занятую работу.

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

Также см. Соотношение тестового кода SQLite к рабочему коду

Answer 2

Одна из вещей, которая направляет меня, когда я пишу тесты или делаю TDD (что я случайно узнал из ответа на один из моих вопросов о SO), заключается в том, что вам не нужно быть настолько осторожным в отношении дизайна / архитектуры вашего проверяет столько, сколько вам нужно, чтобы ваш реальный код. Тесты могут быть немного грязными и неоптимальными (с точки зрения дизайна кода), если они правильно выполняют свою работу. Как и все советы по дизайну, он должен применяться разумно, и ничто не заменит опыт.

Answer 3

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

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

Об отказе от тестов: если вы не тестируете определенные части своего кода, вы фактически подрываете саму концепцию и цель тестов, и тогда тесты фактически бесполезны.

Вы делаетенет, однако, тестовые материалы, которые вы не написали.То есть вы предполагаете, что внешние библиотеки работают должным образом, и сгенерированные методы getter / setter (если ваш язык их поддерживает) также не нужно тестировать.Можно с уверенностью предположить, что при присвоении значения переменной не произойдет сбой.