Покрытие unit-тестами

Зачастую бытует мнение, что 100% покрытие - это норма. То есть покрытие всех строчек кода, как, например, было показано в предыдущей части. Обращаясь к концепции "хорошо" и "правильно" можно сказать, что это - "правильно". Но реальном мире всё намного сложнее. "Бизнес" (заказчик) требует жертв. Ибо пока вы будете писать тесты, то другой "бизнес" выкинет на рынок свой не протестированный продукт и захватит нишу, пока вы будете писать ваши супер тесты. Именно поэтому, 100% покрытие - это заблуждение.

Покрывать тестами все строчки всех классов - это, по меньшей мере, нецелесообразно.

Причин, на самом деле несколько: 

• Затратно по времени, если покрывать все строки кода.
• Всё уже покрыта тестами в сторонних сборках другими разработчиками
• Изменения в классах (unit'ы), которые не участвуют в бизнес процессах

Что рекомендуется покрывать тестами:

• Процессы бизнес-логики
• Классы меняющие процессы (например или обычно, реализуемые паттерны)

Что рекомендуется покрывать тестами:

• Процессы бизнес-логики
• Классы меняющие процессы (например или обычно, реализуемые паттерны)

В этом видео: Создать механизмы для облегчения и упрощения создания тестов. Написать тесты на UnitOfWork (в реализации Nimble Framework).

Видео