На $footsteps 100 поведение провальное. Для того чтобы покрыть такие кейсы нужно перебирать все варианты до какого-то предела или тестировать значения которые в ифах?
подскажите на ваш взгляд где лучше хранить модульные тесты, придерживаться стандартного пути project/tests/Unit или например в областях бизнес логики например project/src/Article/Tests/Unit? последний подход вроде по удобней будет? открыл область логики и все в одном месте будет рядом?
Расположение модульных тестов рядом с логикой принято, например, в экосистеме языка golang. Но даже там для себя нахожу удобнее выделение в отдельное пространство (директорию) tests. И такой подход чаще встречал в корпоративной разработке. Но это скорее вопрос вкуса. Единственный аргумент в пользу отдельной папки tests - если есть модульные тесты, значит скорее всего есть интеграционные и функциональные, которые захватывают много слоев приложения. Для них точно нужна папка tests - а раз так, располагая модульные тесты ближе к проверяемым классам, получается что используем 2 разных подхода в расположении тестов.
А если реальный код на проекте обращается к чужому API в котором изменилась структура данных, то подменять get data плохо. У вас тест пройдет, а на продакшене не будет работать.
Если внешнее API меняет структуру данных без версионирования и выкатывается в доступ, то это очень плохое и странное API. Вопрос к вендору. Но это дичь. Но, если от этого хочется защищаться, то на проде должен быть механизм маппинга и логирование ошибок. Тест не спасет от таких ситуаций никак - ведь тестирование происходит не каждый момент времени, а обычно только при деплое новых версий. API в вашем примере может отчудить в любой момент. Жизненный цикл приложения и API не взаимосвязаны, если речь идёт про внешнее API. Если это внутреннее API, то значит проблема в рабочих процессах и тесты здесь тоже не причем.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Более 4 лет работаю на php, но в ваших видео нахожу много полезного для себя. Спасибо. Жаль что редко выпускаете.
Спасибо за видео - теперь какое то понятия о stub и mock имеется)
Спасибо огромное за вашу работу. Очень понравилось видео !
Спасибо, просто и понятно!)
Классный урок. Это скорее не шпаргалка а полноценный мини курс) Спасибо
Лучшее объяснение которое встречал)
Спасибо, коротко и ясно.
Спасибо!
Её чувак.СПАСИБО!
Лайк однозначно)
Если использовать класс реализацию и ввести 100 или 1000 программа сломается. Странно что вы допускаете такие простейшие ошибки.
Отличная инфа и подача. Могли бы вы снять про тест задания, очереди от Laravel?
А где посмотреть про вызов метода с аргументами можно? Очень надо
На $footsteps 100 поведение провальное. Для того чтобы покрыть такие кейсы нужно перебирать все варианты до какого-то предела или тестировать значения которые в ифах?
подскажите на ваш взгляд где лучше хранить модульные тесты, придерживаться стандартного пути project/tests/Unit или например в областях бизнес логики например project/src/Article/Tests/Unit? последний подход вроде по удобней будет? открыл область логики и все в одном месте будет рядом?
Расположение модульных тестов рядом с логикой принято, например, в экосистеме языка golang. Но даже там для себя нахожу удобнее выделение в отдельное пространство (директорию) tests. И такой подход чаще встречал в корпоративной разработке.
Но это скорее вопрос вкуса. Единственный аргумент в пользу отдельной папки tests - если есть модульные тесты, значит скорее всего есть интеграционные и функциональные, которые захватывают много слоев приложения. Для них точно нужна папка tests - а раз так, располагая модульные тесты ближе к проверяемым классам, получается что используем 2 разных подхода в расположении тестов.
cool
А если реальный код на проекте обращается к чужому API в котором изменилась структура данных, то подменять get data плохо. У вас тест пройдет, а на продакшене не будет работать.
Если внешнее API меняет структуру данных без версионирования и выкатывается в доступ, то это очень плохое и странное API. Вопрос к вендору. Но это дичь.
Но, если от этого хочется защищаться, то на проде должен быть механизм маппинга и логирование ошибок. Тест не спасет от таких ситуаций никак - ведь тестирование происходит не каждый момент времени, а обычно только при деплое новых версий. API в вашем примере может отчудить в любой момент. Жизненный цикл приложения и API не взаимосвязаны, если речь идёт про внешнее API.
Если это внутреннее API, то значит проблема в рабочих процессах и тесты здесь тоже не причем.
@@АндрейШестаков-н6м спасибо!)
Спасибо! Это значит PHP Test да? Вы знаете, что такое Moodle php Test ? Спасибо!
Только в A TRIP не through, а thorough
фига пхпшник с целыми зубами и не бомжастого вида
Ты с 2001 года к нам пожаловал?
Спасибо!