# Модульное/юнит/компонентное тестирование (Module/Unit/Component testing) С этими терминами часто происходит путаница. Если ссылаться на глоссарий ISTQB, то все они - синонимы: * ***Модуль, юнит (module, unit): См. компонент.*** * ***Модульное, юнит тестирование (module testing, unit testing): См. компонентное тестирование.*** * ***Компонент (component): Наименьший элемент программного обеспечения, который может быть протестирован отдельно.*** * ***Компонентное тестирование (component testing): Тестирование отдельных компонентов программного обеспечения (IEEE 610).*** Тем не менее, некоторые источники описывают ситуацию несколько иначе и я решил выписать другую точку зрения. **Модульное тестирование (оно же юнит-тестирование)** используется для тестирования какого-либо одного логически выделенного и изолированного элемента системы (отдельные методы класса или простая функция, subprograms, subroutines, классы или процедуры) в коде. Очевидно, что это тестирование методом белого ящика и чаще всего оно проводится самими разработчиками. Целью тестирования модуля является не демонстрация правильного функционирования модуля, а демонстрация наличия ошибки в модуле, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. На уровне модульного тестирования проще всего обнаружить дефекты, связанные с алгоритмическими ошибками и ошибками кодирования алгоритмов, типа работы с условиями и счетчиками циклов, а также с использованием локальных переменных и ресурсов. Ошибки, связанные с неверной трактовкой данных, некорректной реализацией интерфейсов, совместимостью, производительностью и т.п. обычно пропускаются на уровне модульного тестирования и выявляются на более поздних стадиях тестирования. Изоляция тестируемого блока достигается с помощью заглушек (stubs), манекенов (dummies) и макетов (mockups). **Компонентное тестирование** - тип тестирования ПО, при котором тестирование выполняется для каждого отдельного компонента отдельно, без интеграции с другими компонентами. Его также называют модульным тестированием (Module testing), если рассматривать его с точки зрения архитектуры. Как правило, любое программное обеспечение в целом состоит из нескольких компонентов. Тестирование на уровне компонентов (Component Level testing) имеет дело с тестированием этих компонентов индивидуально. Это один из самых частых типов тестирования черного ящика, который проводится командой QA. Для каждого из этих компонентов будет определен сценарий тестирования, который затем будет приведен к Test case высокого уровня -> детальным Test case низкого уровня с предварительными условиями. Исходя из глубины уровней тестирования, компонентное тестирование можно классифицировать как: * Тестирование компонентов в малом (CTIS - Component testing In Small): тестирование компонентов может проводиться с или без изоляции остальных компонентов в тестируемом программном обеспечении или приложении. Если это выполняется с изоляцией другого компонента, то это называется CTIS; * Тестирование компонентов в целом (CTIL - Component testing In Large) - тестирование компонентов, выполненное без изоляции других компонентов в тестируемом программном обеспечении или приложении. | **Module/Unit testing** | **Component testing** | | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Тестирование отдельных классов, функций для демонстрации того, что программа выполняется согласно спецификации | Тестирование каждого объекта или частей программного обеспечения отдельно с или без изоляции других объектов | | Проверка в(на) соответствии с design documents | Проверка в(на) соответствии с test requirements, use case | | Пишутся и выполняются разработчиками | Тестировщиками | | Выполняется первым | Выполняется после Unit | Другой источник: По-существу эти уровни тестирования представляют одно и тоже, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном/unit тестировании - конкретные значения. \*В контексте юнит-тестирования еще можно встретить понятие [golden testing](https://ro-che.info/articles/2017-12-04-golden-tests). Оно означает те же юнит тесты, но с ожидаемыми результатами хранящимися в отдельном файле. Таким образом после прогона выходные значения тестов сравниваются с golden (эталонным) файлом. \*Иногда юнит-тесты называют одинокими (solitary) в случае тотального применения имитаций и заглушек или общительными (sociable) в случае реальных коммуникаций с другими участниками. \*Правило трех А(AAA) (arrange, act, assert) или триада «дано, когда, тогда» - хорошая мнемоника, чтобы поддерживать хорошую структуру тестов. Источники: * [What is Component Testing? Techniques, Example Test Cases](https://www.guru99.com/component-testing.html) * [Лекция 5: Модульное и интеграционное тестирование](https://intuit.ru/studies/courses/48/48/lecture/1432) Доп. материал: * [ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013](https://docs.cntd.ru/document/1200134996) “D.11 Подпроцесс покомпонентного тестирования” * [Я сомневался в юнит-тестах, но…](https://habr.com/ru/company/skyeng/blog/521324/) * [Юнит-тесты переоценены](https://habr.com/ru/company/qiwi/blog/510608/) * [Elliotte Rusty Harold - Effective Unit Testing](https://www.youtube.com/watch?v=QYj7MLumImM\&ab_channel=Heisenbug) * [Kevlin Henney - What we talk about when we talk about unit testing](https://www.youtube.com/watch?v=-WWIeXmm4ec\&ab_channel=Heisenbug) * [Андрей Сербин - Компонентное тестирование инфраструктуры](https://www.youtube.com/watch?v=hRg_HKB4Fbc\&ab_channel=Heisenbug) * [Анатомия юнит тестирования](https://habr.com/ru/post/507594/) * [Unit Test](https://martinfowler.com/bliki/UnitTest.html) * [Component Test](https://martinfowler.com/bliki/ComponentTest.html) * [Анатомия юнит-теста](https://habr.com/ru/post/554808/) * [Почему большинство юнит тестов - пустая трата времени? (перевод статьи)](https://habr.com/ru/post/557824/) * [Unit Testing Guide](https://www.softwaretestingmaterial.com/unit-testing/) * [Лекция 2: Тестирование программного кода (методы+окружение)](https://intuit.ru/studies/courses/1040/209/lecture/5385) * [Starting to Unit Test: Not as Hard as You Think](https://www.amazon.com/Starting-Unit-Test-Hard-Think-ebook/dp/B00KIZ6JAC/) * [6 оправданий для того, чтобы не писать юнит-тесты](https://testengineer.ru/opravdaniya-dlya-togo-chtoby-ne-pisat-yunit-testy/) * [Принципы юнит-тестирования. Часть первая](https://habr.com/ru/company/sportmaster_lab/blog/676840/) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vladislaveremeev.gitbook.io/qa_bible/vidy-metody-urovni-testirovaniya/modulnoe-yunit-komponentnoe-testirovanie-module-unit-component-testing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.