|
|
# Cобеседование по Java. Разбор вопросов и ответов.
|
|
|
|
|
|
|
|
|
<a href="https://mc.yandex.ru/pixel/8711235002931986822?rnd=%aw_random%">
|
|
|
<img src="https://mc.yandex.ru/pixel/8711235002931986822?rnd=%aw_random%" />
|
|
|
</a>
|
|
|
<a href="https://mc.yandex.ru/watch/92801430">
|
|
|
<img src="https://mc.yandex.ru/watch/92801430" />
|
|
|
</a>
|
|
|
|
|
|
|
|
|
Нажмите ★, если вам нравится проект. Ваш вклад сердечно ♡ приветствуется.
|
|
|
|
|
|
Если вам интересно мое резюме: https://github.com/DEBAGanov
|
|
|
|
|
|
|
|
|
|
|
|
# Тестирование
|
|
|
- [Cобеседование по Java. Разбор вопросов и ответов.](#cобеседование-по-java-разбор-вопросов-и-ответов)
|
|
|
- [Тестирование](#тестирование)
|
|
|
- [Что такое _«модульное тестирование»_?](#что-такое-модульное-тестирование)
|
|
|
- [Что такое _«компонентное тестирование»_?](#что-такое-компонентное-тестирование)
|
|
|
- [Что такое _«интеграционное тестирование»_?](#что-такое-интеграционное-тестирование)
|
|
|
- [Чем интеграционное тестирование отличается от модульного?](#чем-интеграционное-тестирование-отличается-от-модульного)
|
|
|
- [Какие существуют виды тестовых объектов?](#какие-существуют-виды-тестовых-объектов)
|
|
|
- [Чем _stub_ отличается от _mock_?](#чем-stub-отличается-от-mock)
|
|
|
- [Что такое _«фикстуры»_?](#что-такое-фикстуры)
|
|
|
- [Какие аннотации фикстур существуют в JUnit?](#какие-аннотации-фикстур-существуют-в-junit)
|
|
|
- [Для чего в JUnit используется аннотация `@Ignore`?](#для-чего-в-junit-используется-аннотация-ignore)
|
|
|
- [Источники](#источники)
|
|
|
|
|
|
|
|
|
|
|
|
## Что такое _«модульное тестирование»_?
|
|
|
__Модульное/компонентное тестирование (unit testing)__ - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.
|
|
|
|
|
|
Модульные тесты можно условно поделить на две группы:
|
|
|
|
|
|
+ _тесты состояния (state based)_, проверяющие что вызываемый метод объекта отработал корректно, проверяя состояние тестируемого объекта после вызова метода.
|
|
|
|
|
|
+ _тесты взаимодействия (interaction tests)_, в которых тестируемый объект производит манипуляции с другими объектами. Применяются, когда требуется удостовериться, что тестируемый объект корректно взаимодействует с другими объектами.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Что такое _«компонентное тестирование»_?
|
|
|
Проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). Обычно проводится вызывая код, который необходимо проверить и при поддержке сред разработки, таких как фреймворки (frameworks - каркасы) для модульного тестирования или инструменты для отладки.
|
|
|
|
|
|
По-существу компонентные и модульные тестирования представляют одно и тоже, разница лишь в том, что в компонентном тестировании в качестве параметров функций используют реальные объекты и драйверы, а в модульном тестировании - конкретные значения.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Что такое _«интеграционное тестирование»_?
|
|
|
__Интеграционное тестирование (integration testing)__ — это тестирование, проверяющие работоспособность двух или более модулей системы в совокупности — то есть нескольких объектов как единого блока. В тестах взаимодействия же тестируется конкретный, определенный объект и то, как именно он взаимодействует с внешними зависимостями.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Чем интеграционное тестирование отличается от модульного?
|
|
|
С технологической точки зрения интеграционное тестирование является количественным развитием модульного, поскольку так же, как и модульное тестирование, оперирует интерфейсами модулей и подсистем и требует создания тестового окружения, включая заглушки на месте отсутствующих модулей. Основная разница между модульным и интеграционным тестированием состоит в целях, то есть в типах обнаруживаемых дефектов, которые, в свою очередь, определяют стратегию выбора входных данных и методов анализа.
|
|
|
|
|
|
> Допустим, есть класс, который при определенных условиях взаимодействует с web-сервисом через зависимый объект. И нам надо проверить, что определенный метод зависимого объекта действительно вызывается. Если в качестве зависимого класса передать:
|
|
|
|
|
|
> + реальный класс, работающий с web-сервисом, то это будет интеграционное тестирование.
|
|
|
|
|
|
> + заглушку, то это будет тестирование состояния.
|
|
|
|
|
|
> + шпиона, а в конце теста проверить, что определенный метод зависимого объекта действительно был вызван, то это будет тест взаимодействия.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Какие существуют виды тестовых объектов?
|
|
|
__пустышка (dummy)__ - объект, который обычно передается в тестируемый класс в качестве параметра, но не имеет поведения: с ним ничего не происходит и никакие его методы не вызываются.
|
|
|
|
|
|
> Примером dummy-объектов являются new object(), null, «Ignored String» и т.д.
|
|
|
|
|
|
__фальшивка (fake object)__ применяется в основном для ускорения запуска ресурсоёмких тестов и является заменой тяжеловесного внешнего зависимого объекта его легковесной реализацией.
|
|
|
|
|
|
> Основные примеры — эмулятор базы данных (fake database) или фальшивый web-сервис.
|
|
|
|
|
|
__заглушка (test stub)__ используется для получения данных из внешней зависимости, подменяя её. При этом заглушка игнорирует все данные поступающие из тестируемого объекта, возвращая заранее определённый результат.
|
|
|
|
|
|
> Тестируемый объект использует чтение из конфигурационного файла? Тогда передаем ему заглушку `ConfigFileStub` возвращающую тестовые строки конфигурации без обращения к файловой системе.
|
|
|
|
|
|
__шпион (test spy)__ - разновидность заглушки, которая умеет протоколировать сделанные к ней обращения из тестируемой системы, чтобы проверить их правильность в конце теста. При этом фиксируется количество, состав и содержание параметров вызовов.
|
|
|
|
|
|
> Если существует необходимость проверки, что определённый метод тестируемого класса вызывался ровно 1 раз, то шпион - имменно то, что нам нужно.
|
|
|
|
|
|
__фикция (mock object)__ похож на _шпиона_, но обладает расширенной функциональностью, заранее заданными поведением и реакцией на вызовы.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Чем _stub_ отличается от _mock_?
|
|
|
_stub_ используется как заглушка сервисов, методов, классов и т.д. с заранее запрограммированным ответом на вызовы.
|
|
|
|
|
|
_mock_ использует подмену результатов вызова, проверяет сам факт взаимодействия, протоколирует и контролирует его.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Что такое _«фикстуры»_?
|
|
|
__Фикстуры (fixtures)__ - состояние среды тестирования, которое требуется для успешного выполнения теста. Основная задача фикстур заключается в подготовке тестового окружения с заранее фиксированным/известным состоянием, чтобы гарантировать повторяемость процесса тестирования.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Какие аннотации фикстур существуют в JUnit?
|
|
|
|
|
|
+ `@BeforeClass` - определяет код, который должен единожды выполниться перед запуском набора тестовых методов.
|
|
|
+ `@AfterClass` - код, выполняемый один раз после исполнения набора тестовых методов.
|
|
|
+ `@Before` - определяет код, который должен выполняться каждый раз перд запуском любого тестовым методом.
|
|
|
+ `@After` - код, выполняемый каждый раз после исполнения любого тестового метода.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
## Для чего в JUnit используется аннотация `@Ignore`?
|
|
|
`@Ignore` указывает JUnit на необходимость пропустить данный тестовый метод.
|
|
|
|
|
|
[к оглавлению](#Тестирование)
|
|
|
|
|
|
# Источники
|
|
|
+ [Википедия](https://ru.wikipedia.org/wiki/Тестирование_программного_обеспечения)
|
|
|
+ [Хабрахабр](https://habrahabr.ru/post/116372/)
|
|
|
+ [Интуит](http://www.intuit.ru/department/se/testing/5/2.html)
|
|
|
|
|
|
[Вопросы для собеседования](README.md)
|
