LINUX.ORG.RU

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

 


0

3

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

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

★★★★★

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

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

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

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

Hater ★★
()

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

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

vertexua ★★★★★
()

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

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

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

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

umren ★★★★★
()
Ответ на: комментарий от Hater

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

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

Hater ★★
()
Ответ на: комментарий от vertexua

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

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

UVV ★★★★★
() автор топика
Ответ на: комментарий от UVV

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

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)

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

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

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

man dependency inversion
man mock objects

Manhunt ★★★★★
()

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Manhunt

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от AoD314

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

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)

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

dizza ★★★★★
()
Ответ на: комментарий от vertexua

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

dizza ★★★★★
()
Ответ на: комментарий от dizza

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

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

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

dizza ★★★★★
()
Последнее исправление: dizza (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.