лекция для чатика пхпГиков

Ну, есть unit-тесты, есть функциональное тестирование. Про первое рассказывать нужно?

Киньте кто нибудь статью о видах тестирвоания - модульные, функциональные, интеграционные, хочу разобраться что к чему) Ну или если кто то больно умный можете на своих словах объяснить)

и по автотестам бы еще что нибудь

да

Ну, есть unit-тесты, есть функциональное тестирование. Про первое рассказывать нужно?

да

давно пора начать хуячить через TDD

давно пора начать хуячить через TDD

echo $out;die;

мой тест драйв

print_r($out);die;

Сперва про второе. Функ. тестирование — это описание того, как должно работать приложение. В идеале, это форма для заполнения. В РБТ у нас были гугло-формы. Проходишься по ним, кликаешь по сайтику. Если что-то отличается от написанного, заводишь багв джире. Как-то так.

Сперва про второе. Функ. тестирование — это описание того, как должно работать приложение. В идеале, это форма для заполнения. В РБТ у нас были гугло-формы. Проходишься по ним, кликаешь по сайтику. Если что-то отличается от написанного, заводишь багв джире. Как-то так.

То есть функциональное - это ручное тестирование получается?

Но это пиздец пиздецкий. Обезьянья работа. Лучше свести необходимость в ней к минимому и отдать а аутсорс.

Ага.

Юнит-тесты работают так:

https://habrahabr.ru/post/138223/ просто тут вроде описывается автоматизация этого процесса

я вот и запутался

я зашёл на кодеварс и там увидел либру с юнит тестами так и запутался

<?php $I = new WebGuy($scenario); $I->wantTo('see my site is working'); $I->amOnPage('/'); $I->see('Welcome, on my site!'); ?>

Ты подключаешь тестируемую функцию, подменяешь её зависимости заглушками, вызываешь её с разными аргументами, заранее объявляя результат, или его признаки, который она должна вернуть. Если не сходится, тест падает с подробным отчётом о несовпадении в виде DIFF'а.

магия

Ты подключаешь тестируемую функцию, подменяешь её зависимости заглушками, вызываешь её с разными аргументами, заранее объявляя результат, или его признаки, который она должна вернуть. Если не сходится, тест падает с подробным отчётом о несовпадении в виде DIFF'а.

а есть видеокурсы по этой штуке?

Ты подключаешь тестируемую функцию, подменяешь её зависимости заглушками, вызываешь её с разными аргументами, заранее объявляя результат, или его признаки, который она должна вернуть. Если не сходится, тест падает с подробным отчётом о несовпадении в виде DIFF'а.

это ты модульные тесты описал, как я понял?

это ты модульные тесты описал, как я понял?

это юнит

https://habrahabr.ru/post/138223/ просто тут вроде описывается автоматизация этого процесса

Ну, вроде как, функ. тестирование можно на фронтенде автоматизировать. Это всё, что я знаю. Достаточно сложный стек. В РБТ мы до него не дошли, а на текущем месте необходимость отсутствует — нам всё это заменят юнит-тесты, ибо реакт.

Ты подключаешь тестируемую функцию, подменяешь её зависимости заглушками, вызываешь её с разными аргументами, заранее объявляя результат, или его признаки, который она должна вернуть. Если не сходится, тест падает с подробным отчётом о несовпадении в виде DIFF'а.

Это юнит-тестирование.

Ок, давайте теперь с интеграционными)

я проделал вот примеры с сайта - https://docs.docker.com/docker-for-windows/ но я немного не понимаю где мой код будет? у меня же на машине не в контейнере

просто очень круто получается. весь прод софт стоит, разварачивается быстро и юзай под виндой как на линхе https://habrahabr.ru/post/315738/

Ок, давайте теперь с интеграционными)

Вообще никогда не использовал такой термин. Гугл говорит, что это тестирование взаимодествия твоих модулей. В общем, да, есть смысл выделить это в отдельную категорию.

По логике: Если ты тестируешь все свои функции, подменяя все их зависимости заглушками, ты сразу определяешь, какой модуль работает неправильно и ловишь баги.

НО

Тебе нужно быть уверенным, в том, что верна сама архитектура, что твои компоненты совместимы.

Вообще никогда не использовал такой термин. Гугл говорит, что это тестирование взаимодествия твоих модулей. В общем, да, есть смысл выделить это в отдельную категорию.

ну ты сливаешь все функциональные ветки в интеграционную (релизную по сути) и тестируешь ее. но это не точно :)

Они могут работать правильно с автономной точки зрения, но они могут быть неверно спроектирваны в контексте системы.

ну ты сливаешь все функциональные ветки в интеграционную (релизную по сути) и тестируешь ее. но это не точно :)

Не. Смотри не в разрезе версионирования, а в разрезе архитектуры.

Не. Смотри не в разрезе версионирования, а в разрезе архитектуры.

я тебе про интеграционное тестирование :)

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

чет я не понял что имеется ввиду под компонентами. Микросервисы, разные классы, или что?

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

я вообще не вдпуляю пока как их писать

примеры какие то убогие везде

я вообще не вдпуляю пока как их писать

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

assertEqual

и все

Короче. Опять же, на предыдущем месте, у нас не было необходимости в интеграционном тестировании, т.к. все юнит-тесты писались без заглушек. В результате, если они где-то падали, то падали и все тесты зависимого кода. Это затрудняло поиск ошибки, но избавляло от необходимости понимания, что стоит подумать о тестировании взаимодествия компонентов.

чет я не понял что имеется ввиду под компонентами. Микросервисы, разные классы, или что?

Как правило, компоненты одного приложения.

а вот если без заглушек(моканье вроде же = заглушки?) то как например тестируются методы создания новой сущности

например есть у меня какой то объект фабрика, который занимается клонированием

за рекламу того канала я больше предупреждать не буду. сразу в бан

телеговский для похапешников

злые они)

и как от проверить что он создаст клон корректно и свяжет с новой сущностью в базе

за рекламу того канала я больше предупреждать не буду. сразу в бан

это где?

и как от проверить что он создаст клон корректно и свяжет с новой сущностью в базе

Из юнит-тестов нужно убрать всё взаимодействие со внешними системами. ТЕстирование работы непосредственно с БД — хз, как делать. =) Я об этом не думал. У меня нет такой необходимости, в принципе.

например есть у меня какой то объект фабрика, который занимается клонированием

Есть всякие accertion-библиотеки, которые могут сопоставлять твои требования с реальным результатом. Это нужно загуглить и почитать. Там довольно мощный инструментарий.

это канал ж для пхп)

Ребят можно вопрос по го?

плиз

есть чат по го)

о влс

Ну до конца не разорался но чуть полегче стало)

Вообще хорошо бы книжку почитать про это дело)

Ну до конца не разорался но чуть полегче стало)

phpunit

эт я сморел

Попробуй написать пару тестов для простых функций без зависимостей.

https://phpunit.de/getting-started.html

я вот не понял их пример

ERROR: S client not available

что он нам вообще дает

$this->assertEquals(-1, $b->getAmount());

чего ожидать от этой функции

assertEquals() проверяет соответствие.

есть еще assertSame() интересная штука, было открытием для меня :)

Там может быть не только -1, но и два массива в разном порядке.

Или два разных объекта.

Но если они соответствуют, assertEquals одобрит.

А если не одобрит?

то это как ошибка будет и тест не пройден?

да

на то он и assert

Вывалит исключение в консоль с ошибкой и, что главное — DIFF'ом.

То есть ты сразу увидишь, чем отличаются ожидаемый и реальный результаты.

Ну и вот мы подошли к основной причине моего непонимания, что нам этот тест дает то по факту? типо мы в будущем сможем что то поменять в классе Money и поломать метод Negate и незаметить, а тесты нам помогут в этом?

Ага.

Если поведение изменяется по-плану (типа так и надо), актуализируются и тесты. Это и есть TDD: тесты — это документация.

я дуал tdd это когда сначало тесты пишешь, и потом под них подгоняешь прогу)

типа сначала нахерачить тесты, а только потом код?

вот да

я тоже так думал про TDD

я дуал tdd это когда сначало тесты пишешь, и потом под них подгоняешь прогу)

Ну, в идеале, да. =))

Но все мы грешны.

В идеале так проще, т.к. ты уже никогда не забудешь, как работает функция. А если будешь писать тесты через полгода, то можешь и не узнать свой код.

есть еще прикольный прикол

тесты на тесты

Профит есть. Но спроектировать всё так круто, чтобы заранее была видня вся-вся-вся архитектура, сложно.

тесты на тесты

Чур меня.

тесты на тесты

а потом тесты на тесты для тестов?

когда какой-то тест становится слишком уж большим и комплексным, но так надо, то на него пишется еще один маленький тест, который поможет понять, что тот большой правильно работает :)

более, чем реальная практика, но тут ключевое слово "вынужденно очень большой и сложный тест"

т.к. в идеале тест должен быть неимоверно простым