Шпаргалка: unit тестирование. Fake, stub, mock. Примеры на PHPUnit.
Вставка
- Опубліковано 22 сер 2024
- 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... - кошелек.
Более 4 лет работаю на php, но в ваших видео нахожу много полезного для себя. Спасибо. Жаль что редко выпускаете.
Спасибо за видео - теперь какое то понятия о stub и mock имеется)
Спасибо огромное за вашу работу. Очень понравилось видео !
Классный урок. Это скорее не шпаргалка а полноценный мини курс) Спасибо
Лучшее объяснение которое встречал)
Спасибо, просто и понятно!)
Если использовать класс реализацию и ввести 100 или 1000 программа сломается. Странно что вы допускаете такие простейшие ошибки.
Её чувак.СПАСИБО!
Лайк однозначно)
Спасибо, коротко и ясно.
Спасибо!
Отличная инфа и подача. Могли бы вы снять про тест задания, очереди от Laravel?
cool
На $footsteps 100 поведение провальное. Для того чтобы покрыть такие кейсы нужно перебирать все варианты до какого-то предела или тестировать значения которые в ифах?
подскажите на ваш взгляд где лучше хранить модульные тесты, придерживаться стандартного пути project/tests/Unit или например в областях бизнес логики например project/src/Article/Tests/Unit? последний подход вроде по удобней будет? открыл область логики и все в одном месте будет рядом?
Расположение модульных тестов рядом с логикой принято, например, в экосистеме языка golang. Но даже там для себя нахожу удобнее выделение в отдельное пространство (директорию) tests. И такой подход чаще встречал в корпоративной разработке.
Но это скорее вопрос вкуса. Единственный аргумент в пользу отдельной папки tests - если есть модульные тесты, значит скорее всего есть интеграционные и функциональные, которые захватывают много слоев приложения. Для них точно нужна папка tests - а раз так, располагая модульные тесты ближе к проверяемым классам, получается что используем 2 разных подхода в расположении тестов.
Спасибо! Это значит PHP Test да? Вы знаете, что такое Moodle php Test ? Спасибо!
А где посмотреть про вызов метода с аргументами можно? Очень надо
А если реальный код на проекте обращается к чужому API в котором изменилась структура данных, то подменять get data плохо. У вас тест пройдет, а на продакшене не будет работать.
Если внешнее API меняет структуру данных без версионирования и выкатывается в доступ, то это очень плохое и странное API. Вопрос к вендору. Но это дичь.
Но, если от этого хочется защищаться, то на проде должен быть механизм маппинга и логирование ошибок. Тест не спасет от таких ситуаций никак - ведь тестирование происходит не каждый момент времени, а обычно только при деплое новых версий. API в вашем примере может отчудить в любой момент. Жизненный цикл приложения и API не взаимосвязаны, если речь идёт про внешнее API.
Если это внутреннее API, то значит проблема в рабочих процессах и тесты здесь тоже не причем.
@@user-wz6yb6cp7o спасибо!)
Только в A TRIP не through, а thorough
фига пхпшник с целыми зубами и не бомжастого вида
Ты с 2001 года к нам пожаловал?
Спасибо!