Шпаргалка: unit тестирование. Fake, stub, mock. Примеры на PHPUnit.

t.me/phpashest... - php телеграмм канал.
t.me/phpmentor - eng php телеграмм канал.
#phpunit #stub #mock #unitтестирование #unitтесты #fake
github.com/aas... - код из видео.
9:20 - Fake
11:51 - Stub
15:41 - Mock
Аббревиатура ATRIP.
A - Automatic - означает, что тесты должны запускаться автоматически и быть неотъемлемой частью процесса сборки.
T - THROUGH - означает целостность, покрытие всевозможных кейсов тестируемого модуля. Например, если ваш код ведет себя по-разному в зависимости от часового пояса клиента, то можно будет утверждать о качественно написанном тесте, если он покроет все возможные варианты часовых поясов.
R - repeatable. Повторяемость теста означает, что один и тот же тест должен всегда выдавать одинаковый результат на одинаковые входящие данные. Тест не должен зависеть от каких-то внешних факторов. Если вы прогоняете тест миллион раз и 1 раз тест выдал ошибку, значит тест составлен не корректно.
I - Independent. Независимость, и это очень важный критерий. Все модульные тесты должны быть изолированных друг от друга, не должны влиять друг на друга. Каждый тест можно запустить отдельно, любой набор тестов можно запускать в любом порядке и результат всегда должен быть одинаков - это признаки хорошо составленных тестов. Состояние системы должно нормализоваться, то есть возвращаться к исходному перед каждым отдельно взятым тестом. Так же не должно быть зависимости от внешних систем, например, сторонних сервисов, которые могут быть недоступны в какой-то момент времени.
P - professional. Тесты должны быть выполнены профессионально, ведь тесты - это точно такой же код, как и остальная часть программы. Соответственно к тестам можно и нужно применять лучшие практики программирования.
Буду рад поддержке: лайк, комментарий (адекватная критика тоже приветствуется), денюжка - все мотивирует в плюс.
www.donational... - кошелек.

[@justr4390]

Более 4 лет работаю на php, но в ваших видео нахожу много полезного для себя. Спасибо. Жаль что редко выпускаете.

[@sani4051992]

Спасибо за видео - теперь какое то понятия о stub и mock имеется)

[@lexo6863]

Классный урок. Это скорее не шпаргалка а полноценный мини курс) Спасибо

[@supchic1021]

Спасибо огромное за вашу работу. Очень понравилось видео !

[@user-ql6sq9jb7o]

Если использовать класс реализацию и ввести 100 или 1000 программа сломается. Странно что вы допускаете такие простейшие ошибки.

[@andreyzavgorodniy9749]

Лучшее объяснение которое встречал)

[@zCubEz]

Спасибо, просто и понятно!)

[@pragmatik3353]

Её чувак.СПАСИБО!

[@SergiuSavva]

Спасибо, коротко и ясно.

[@ggyoug]

Спасибо!

[@AlexanderKh-jx7jr]

Отличная инфа и подача. Могли бы вы снять про тест задания, очереди от Laravel?

[@itskhmel]

Лайк однозначно)

[@hanasugisakimusiji]

На $footsteps 100 поведение провальное. Для того чтобы покрыть такие кейсы нужно перебирать все варианты до какого-то предела или тестировать значения которые в ифах?

[@user-sz8ge1my8j]

cool

[@user-gy3fs1mq5z]

подскажите на ваш взгляд где лучше хранить модульные тесты, придерживаться стандартного пути project/tests/Unit или например в областях бизнес логики например project/src/Article/Tests/Unit? последний подход вроде по удобней будет? открыл область логики и все в одном месте будет рядом?

[@user-wz6yb6cp7o]

Расположение модульных тестов рядом с логикой принято, например, в экосистеме языка golang. Но даже там для себя нахожу удобнее выделение в отдельное пространство (директорию) tests. И такой подход чаще встречал в корпоративной разработке. Но это скорее вопрос вкуса. Единственный аргумент в пользу отдельной папки tests - если есть модульные тесты, значит скорее всего есть интеграционные и функциональные, которые захватывают много слоев приложения. Для них точно нужна папка tests - а раз так, располагая модульные тесты ближе к проверяемым классам, получается что используем 2 разных подхода в расположении тестов.

[@syracuse4612]

А где посмотреть про вызов метода с аргументами можно? Очень надо

[@meerimattokur8131]

Спасибо! Это значит PHP Test да? Вы знаете, что такое Moodle php Test ? Спасибо!

[@eugenefedorov3498]

А если реальный код на проекте обращается к чужому API в котором изменилась структура данных, то подменять get data плохо. У вас тест пройдет, а на продакшене не будет работать.

[@user-wz6yb6cp7o]

Если внешнее API меняет структуру данных без версионирования и выкатывается в доступ, то это очень плохое и странное API. Вопрос к вендору. Но это дичь. Но, если от этого хочется защищаться, то на проде должен быть механизм маппинга и логирование ошибок. Тест не спасет от таких ситуаций никак - ведь тестирование происходит не каждый момент времени, а обычно только при деплое новых версий. API в вашем примере может отчудить в любой момент. Жизненный цикл приложения и API не взаимосвязаны, если речь идёт про внешнее API. Если это внутреннее API, то значит проблема в рабочих процессах и тесты здесь тоже не причем.

[@eugenefedorov3498]

@@user-wz6yb6cp7o спасибо!)

[@konstantinsurikov3636]

Только в A TRIP не through, а thorough

[@noone-hi6kq]

фига пхпшник с целыми зубами и не бомжастого вида

[@resolution07]

Ты с 2001 года к нам пожаловал?

[@gunscheler8622]

Спасибо!