Где та грань..

по которой определять, когда нужны unit test'ы, а когда нет.

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

Компонент зависит от third-party библиотеки. Тесты компонента сведутся к тестированию библиотеки?

Нет, такую библиотеку нужно мокать.

В юнит тесте вместо third-party библиотеки сделай mock. Это проверит сам твой компонент

В интеграционном тесте используй настоящую, это проверит правильность использования API в принципе в виде high level сценария.

Тесты компонента сведутся к тестированию библиотеки

свою «бизнес» логику тестируй, а 3rd party компоненты должны тестировать ихние разработчики.

когда нужны unit test'ы, а когда нет.

по хорошему всегда нужны.

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

Ну а по фен-шую идеально было бы каждый отдельный неделимый кусок кода тестировать с наибольшим спектром входных данных.

В юнит тесте вместо third-party библиотеки сделай mock. Это проверит сам твой компонент

Можно пинок в нужном направлении на howto, pls

ЯП встудию

C++, cppunit

Я не уверен что в плюсах есть всякие магические либы, потому просто предлагаю использовать подход Dependency Injection. Тоесть передавать зависимости компонентов класса через конструктор. Таким образом если ты получаешь доступ к компоненту через интерфейс, то можно реализовать этот интерфейс по другому, с заглушками. И в юнит-тесте протестировать что были вызваны методы заглушки. Такие mock классы писать скучно и неинтересно, потому обычно такое умеют всякие магические mock фреймворки делать. Они делают такой подклас интерфейса, что он записывает все вызовы своих методов и можно проверять факт их вызова, очередность и задавать что эти методы возвращают тестируемому компонету

по которой определять, когда нужны unit test'ы, а когда нет.

Поставь цель в 60% branch coverage + хоть какая-то проверка всех «основных» сценариев.

Компонент зависит от third-party библиотеки. Тесты компонента сведутся к тестированию библиотеки?

man dependency inversion
man mock objects

О, вертухай уже всё написал, оказывается.

сделай mock

Что сиё ругательство означает? Эмуль библиотеки, точнее её интерфейса? (я не копенгаген в юнит-тестах)

http://en.wikipedia.org/wiki/Mock_object

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

Тестирование «абы как» равносильно отсутствию каких либо тестов!

Тестирование «абы как» равносильно отсутствию каких либо тестов!

Тестирование «на 100%»:
1. Неосуществимо на практике.
2. Близкие приближения к нему неоправданно дороги.

Конечно, можно попытаться протестировать код на порядок глубже, чем я предложил. Помимо проверки «основных» сценариев, проверить краевые значения, а также попробовать добиться 100% branch coverage (кто-нибудь умеет настроить gcov так, чтобы тот игнорировал не выстрелившие assert-ы?). Но нужно понимать, что это отход от принципа 20/80, и целесообразность поддержки в 10 раз распухшего объема юнит-тестов нужно трезво оценить.

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

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

Трололо: а классы jdk мокать надо? А если нет, то получается что практически все тесты интеграционные? Имхо деление на юнит и интеграционные тесты дурацкое, грань между ними не четкая. Лично я делю тесты на быстрые и медленные.

Обычно интеграционные тесты могут вызывать внешние сервисы. СУБД, создавать файлы. Добавляет нестабильности. Юнит тесты полностью замкнуты

Просто с точки зрения классической формулировки юнит-тест тестирует один класс, а тест проверяющий больше одного класса уже интеграционный. Как-то путаницу пытался исправить Фаулер введя понятие классического теста - это такой интеграционный тест, которые не лезет сильно далеко, только в быстрые стабильные ресурсы (в БД в памяти например). Такой тест можно запускать из IDE и при сборке проекта, но юнит-тестом он не является.