В статье не рассматриваются подробно интеграционные и сквозные тесты. На самом деле видов тестирования сильно больше чем три, но в статье они объединяются в эти три группы. Интеграционные и сквозные тесты похожи между собой тем, что они проверяют взаимодействие, но я постараюсь провести условную границу между ними.
Сквозные тесты все-таки более высокоуровневые и ориентируется на копирование поведения реального пользователя системы - для приложения с UI они могут имитировать щелчки мышки и нажатия клавиш. Для систем без UI - это запросы к публичному API. Такие тесты не зависят от внутренней реализации системы, смотрят на тестируемую систему как на черный ящик (в отдельных случаях как на серый ящик - если нужна специфическая подготовка тестовых данных) и используют тот интерфейс, который использует реальный пользователь - графический интерфейс или публичное API (такой интерфейс чаще всего имеет спецификацию). При таких тестах могут быть задействованы несколько систем сразу. Они оценивают, что система работает так, как ожидалось с точки зрения конечного пользователя. Этим тестам не нужен исходный код тестируемого приложения, они могут быть запущены на отдельной машине, для проверки им нужен лишь адрес тестируемой системы. У нас такие тесты пишут QA-специалисты.
Интеграционный тест чаще всего более низкоуровневый, чем сквозной и может проверять более детализированные взаимодействия - например, взаимодействие модуля приложения с базой данных или взаимодействие двух модулей приложения между собой. Такие тесты учитывают детали реализации, рассматривают систему как белый ящик и часто используют интерфейсы, недоступные снаружи для пользователей. Эти тесты хорошо дополняют юнит-тесты - одни тестируют независимую работу юнитов, другие - взаимодействие этих юнитов между собой. Они используют исходный код тестируемого приложения и чаще всего хранятся вместе с ним. Такие тесты могут запускаться отдельно от юнит-тестов или вместе с ними при сборке приложения. У нас такие тесты пишут разработчики.
Тут правильнее сказать, что отличаются они подходом к изоляции кода - одна школа изолирует код от изменяемых зависимостей, другая - тесты друг от друга. А размер юнита - это следствие из этого. В начале статьи как раз указаны признаки юнит-теста, один из которых - должен поддерживать изоляцию от другого кода, и если оно не выполняется - это уже не юнит-тест.
Так как мы используем подход Лондонской школы, где юнит == класс, то тест, который проверяет этот класс с замоканными изменяемыми зависимостями - это юнит-тест. Если мы такие зависимости не мокаем, а используем реальные классы - то уже интеграционный. Для классической школы чуть сложнее, но думаю возможно провести границу.
Вы правильно заметили, и в статье есть об этом упоминание, что стратегию тестирования стоит определять в том числе исходя из предполагаемой продолжительности жизни продукта. Для MVP, который после может оказаться ненужным или будет переписан заново, стремиться к высокому уровню покрытия тестами наверное излишне. Если проект сложный и долгоиграющий, то идеально задуматься о тестах в самом начале. В этом случае тесты даже могут помочь избежать "большого кома грязи", который будет тяжело тестировать на раннем этапе и заставит задуматься о дизайне кода.
Также есть опыт увеличения покрытия тестами уже написанного приложения - это долго и трудно, сопряжено с неизбежным рефакторингом, но вполне реально.
Тесты как и любой другой инструмент в нашей профессии, будь то статический анализ кода или практики код ревью, должны рассматриваться именно как инструмент, оцениваться с точки зрения применимости и профита от этого в каждом конкретном случае.
Об этом как раз вторая часть статьи, которая планируется чуть позже. В том числе о том, что нужно покрывать, а что нет, что есть код, который сложно покрывать тестами и как можно такой код сделать более тестируемым.
Я считаю такие тесты интеграционными, так как фактически тестируется связка классов. Например, на контроллер можно написать юнит-тест без аннотаций Spring, создав его экземпляр с замокированными изменяемыми зависимостями.
Много написано про подкапотную часть корутин, но эта статья наконец раскладывает нутнянку по полкам. Спасибо, добавил в сохраненные.
Про минусы такого подхода также было сказано - хрупкость тестов. Стоит взвесить плюсы и минусы.
В статье не рассматриваются подробно интеграционные и сквозные тесты. На самом деле видов тестирования сильно больше чем три, но в статье они объединяются в эти три группы. Интеграционные и сквозные тесты похожи между собой тем, что они проверяют взаимодействие, но я постараюсь провести условную границу между ними.
Сквозные тесты все-таки более высокоуровневые и ориентируется на копирование поведения реального пользователя системы - для приложения с UI они могут имитировать щелчки мышки и нажатия клавиш. Для систем без UI - это запросы к публичному API. Такие тесты не зависят от внутренней реализации системы, смотрят на тестируемую систему как на черный ящик (в отдельных случаях как на серый ящик - если нужна специфическая подготовка тестовых данных) и используют тот интерфейс, который использует реальный пользователь - графический интерфейс или публичное API (такой интерфейс чаще всего имеет спецификацию). При таких тестах могут быть задействованы несколько систем сразу. Они оценивают, что система работает так, как ожидалось с точки зрения конечного пользователя. Этим тестам не нужен исходный код тестируемого приложения, они могут быть запущены на отдельной машине, для проверки им нужен лишь адрес тестируемой системы. У нас такие тесты пишут QA-специалисты.
Интеграционный тест чаще всего более низкоуровневый, чем сквозной и может проверять более детализированные взаимодействия - например, взаимодействие модуля приложения с базой данных или взаимодействие двух модулей приложения между собой. Такие тесты учитывают детали реализации, рассматривают систему как белый ящик и часто используют интерфейсы, недоступные снаружи для пользователей. Эти тесты хорошо дополняют юнит-тесты - одни тестируют независимую работу юнитов, другие - взаимодействие этих юнитов между собой. Они используют исходный код тестируемого приложения и чаще всего хранятся вместе с ним. Такие тесты могут запускаться отдельно от юнит-тестов или вместе с ними при сборке приложения. У нас такие тесты пишут разработчики.
Тут правильнее сказать, что отличаются они подходом к изоляции кода - одна школа изолирует код от изменяемых зависимостей, другая - тесты друг от друга. А размер юнита - это следствие из этого. В начале статьи как раз указаны признаки юнит-теста, один из которых - должен поддерживать изоляцию от другого кода, и если оно не выполняется - это уже не юнит-тест.
Так как мы используем подход Лондонской школы, где юнит == класс, то тест, который проверяет этот класс с замоканными изменяемыми зависимостями - это юнит-тест. Если мы такие зависимости не мокаем, а используем реальные классы - то уже интеграционный. Для классической школы чуть сложнее, но думаю возможно провести границу.
Спасибо за развернутый комментарий.
Вы правильно заметили, и в статье есть об этом упоминание, что стратегию тестирования стоит определять в том числе исходя из предполагаемой продолжительности жизни продукта. Для MVP, который после может оказаться ненужным или будет переписан заново, стремиться к высокому уровню покрытия тестами наверное излишне. Если проект сложный и долгоиграющий, то идеально задуматься о тестах в самом начале. В этом случае тесты даже могут помочь избежать "большого кома грязи", который будет тяжело тестировать на раннем этапе и заставит задуматься о дизайне кода.
Также есть опыт увеличения покрытия тестами уже написанного приложения - это долго и трудно, сопряжено с неизбежным рефакторингом, но вполне реально.
Тесты как и любой другой инструмент в нашей профессии, будь то статический анализ кода или практики код ревью, должны рассматриваться именно как инструмент, оцениваться с точки зрения применимости и профита от этого в каждом конкретном случае.
Об этом как раз вторая часть статьи, которая планируется чуть позже. В том числе о том, что нужно покрывать, а что нет, что есть код, который сложно покрывать тестами и как можно такой код сделать более тестируемым.
Я считаю такие тесты интеграционными, так как фактически тестируется связка классов. Например, на контроллер можно написать юнит-тест без аннотаций Spring, создав его экземпляр с замокированными изменяемыми зависимостями.