Несколько простых вопросов по тестированию. Кто поможет?

Question

[Anton Mashletov]

Сел писать свой первый тест (хлоп-хлоп). Помогите разобраться на cферическом примере.
Допустим, есть у меня сайт — таблица пользователей, форма создания/редактирования и просмотр.
Сущности: resource-контроллер UserController, модель User, вьюхи index/create/edit/show.
Все это готово и работает.

То есть, по идее, мне надо убедиться, что:

• открывается главная страница
  
• пользователи добавляются
  
• редактируются
  
• просматриваются
  

Я создал UserTest в папке tests, добавил первую проверку testIndex(), и у меня возникла сразу куча вопросов:

1. Все эти пункты можно выполнить с помощью $this->visit('/users') / see / dontSee / press.
   Это, я так понимаю, функциональное тестирование. Достаточно ли его будет в этой ситуации?
   
2. index еще можно протестировать создав new UserController и вызвав метод index с разными фильтрами (Request) и проверив на ошибки. Тоже самое с моделью, можно сделать: попробовать save с разными параметрами, вместо заполнения формы.Это уже будет Юнит-тест? Нужно ли это если есть п.1 или избыточно?
   
3. Все тесты: и юнит, и функциональные могут находиться в одном файле UserTest?
   Или надо их как-то разделять и по запускать по их типу? Надо ли было делить на что-то типа UserControllerTest, UserModelTest, UserFuncTest?
   
4. Если я с помощью visit добавляю нового пользователя - как откатить изменения или удалить?
   

Comments

[Alexej Simakov]

я с phpunit не работал, но в любом случае, рекомендовал бы разбраться как внутренне работает visit, see, dontSee и press. Я предполагаю что движок php делает вид, что поступил запрос на страницу и генерирует соответствующий документ и с помощью see провереяет содержимое этого документа на наличие определенного содержания. Таким образом он возможно не тестирует рендеринг. Т.е. если у вас две кнопки будут лежать друг на друге php юнит не заметит этого. А selenium, возможно, заметит. Если он щелкает по координатам.
тут про phpunit уже полезный вопрос пролетал недавно Как писать тесты?

[Anton Mashletov]

Alexej Simakov, это был мой вопрос. Я тогда только теоретизировал, а теперь к практике перешёл.

[Alexej Simakov]

Anton Mashletov, бывает, я и не обратил внимания :)

[Lander]

Вообще количество вопросов связанных с тестированием наталкивает на мысль, что данная тема в интернетах освещена слабо. Хотя мне кажется что такие вещи надо объяснять чуть не параллельно с синтаксисом ЯП. Наверное всё таки придётся писать свой учебник с преферансом и барышнями.

[Anton Mashletov]

Lander, лучше, для начала, ответить на мои вопросы :)

Answer 1

[Philipp]

Итак, для начала следует разобраться в разнице между юнит-тестированием, интеграционным тестированием, функциональным тестированием и тестом на регрессии.

Юнит-тестирование предназначено для тестирования конкретного метода или класса.
В вашем случае это будут тесты для модели, например проверка, что модель создает запись в базе с определенной структурой.

Интеграционное тестирование означает проверку совместной работы компонентов системы. Например проверка того, что вызов метода контроллера создает запись в базе с определенной структурой. В данном случае проверяется интеграция контроллера с моделью. Более высокоуровневое интеграционное тестирование может быть проведено на уровне клиента, когда сервис возвращает нужный объект.

Функциональное тестирование проверяет соотвествие требованиям проекта. Например, при нажатии кнопки Удалить появляется окно подтверждение с текстом "Вы уверены", затем при нажатии кнопки "Да", запись удаляется из БД и пользователю выводится сообщение "Запись успешно удалена!".

Тест на регрессию - это повторная проверка работы конкретного участка кода. Как правило это участок кода, который не был покрыт тестами ранее.

PHPUnit изначально предназначен для юнит-тестирования, однако это не мешает вам использовать его для других видов тестирования. Есть даже коннекторы к WebDriver.

Тестирование контроллеров и моделей по отдельности - это юнит-тесты.
Тестирование связки контроллер-модель - это интеграционное тестирование.
Тестрование работы сайта целиком с помощью того же Selenium и т.п. - это функциональное тестирование.

Comments

[Александр Маджугин]

> для модели, например проверка, что модель создает запись в базе с определенной структурой.
Вот тут сразу вопрос - а как это проверить? Создать запись через метод и ... и что? Получить эту запись? Ок. Как? С помощью той же модели которую тестируем?
Если да, то тест модели опирается на модель, которую мы тестируем. Что самое по себе может приводить даже к ложному прохождению теста.
Если нет, то это означает что нам нужно иметь дублирующую модель в тесте. А кто будет тестировать её? Если никто и мы в ней уверены, то почему бы ее не использовать вместо той модели, которую мы собираемся тестировать, и отказаться от тестов?

Т.е. понятно, что на практике эти вопросы встают редко, но все же...

Answer 2

[latteo]

Мне очень помогло вот это видео - https://www.youtube.com/watch?v=8u6_hctdhqI Хотя, стоит заметить, что до него я потратил десятки часов на чтение статей ;)

Хорошей практикой считается создавать suite под разные виды тестов: unit, интеграционные (функциональные), UI
Все они служат для повышение качества софта.

Но unit в первую очередь нужны разработчикам для уверенности при рефакторинге и лучшего понимания чужого кода, конечно, если они написаны не только ради того чтобы было. Они должны быть очень быстрыми и тестировать отдельные участки кода. Для этого при написании таких тестов часто используют моки.

То что вы описали $this->visit('/users') / see / dontSee / press. ближе всего к UI тестам. Это проверка софта с точки зрения пользователя. Очень часто они написаны даже не разработчиком, а QA. Если для их выполнения настроить Selenium, то можно приятно удивить клиента :)

Comments

[Anton Mashletov]

Вчера посмотрел. Всем советую, чувак очень интересно рассказывает про TDD.

[Anton Mashletov]

latteo а чем Selenium, лучше чем $this->visit?

[latteo]

Anton Mashletov, код возможно останется тот же (наверняка есть адаптеры), просто контент вместо загрузки курлом будет загружаться в браузере. Выглядит нагляднее + можно тестировать JS + делать авто скриншоты при ошибке. Из минусов - работает медленнее.