У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?
что такое правильно?
Ale
Ale
оно просто иногда работает и помогает не тратить деньги
Sergey
например вот в случае с этой девчушкой ATDD/BDD хорошо бы сработало (TDD - врядли)
Ale
а иногда нет)
guga
Sergey
У меня вопрос назрел, вот вы все тут про tdd, bdd прочие лучшие практики разговариваете. Как вы понимаете что делаете это правильно, ну и ещё, обычно вы лично внедряете или просто присутствуете в команде, где это уже есть и так делают все?
хз как это правильно. есть опыт, основанный на тонне прочитанной литературы, ревью опенсорс проектов где это используется и смотрим есть ли профит от конкретной практики. если профита нет - значит не так готовим. обычно приходится самим внедрять :(
Sergey
ну это я так трактую
Ale
работает? Почти все работает, чаще вопрос, сколько это стоит сейчас и в будущем
Sergey
именно
Sergey
"правильно" - это значит "работает в данной ситуации"
коннекты к БД из юнит тестов, это не правильно, но работает. так что сомнительное утверждение
Sergey
с учетом краткосрочной и долгосрочной перспектив, с учетом того какие вещи важнее для бизнеса сейчас
Ale
Sergey
всегда можно добавить технического долга
Sergey
а если система разделена более-менее грамотно
Ale
а что такое юнит?
Sergey
репозиторий нужно тестить вместе с базой данных
Sergey
иначе дорого выходит и непонятно что ты проверяшь
Sergey
то есть речь идет о интеграционных тестах
Ale
почему бы не назвать эти тесты на репозиторий юнит тестами? Их поломка точно нам скажет, где проблема
Sergey
юнит то и есть одна единица. а "юнит тест на репозиторий", это взаимодействие 2х обьектов, твоего класса и базы. а это уже нифига не единица
Sergey
а что такое юнит?
юнит - кусочек изолированный от внешнего мира. Юнит тесты - тесты которые гоняются в рамках процесса, то есть не лазают из пространства процесса во "внешний мир", не лазают в базу, не учитываю время системы, не учитывают базу данных, не говорят по сети
Sergey
полная изоляция от внешнего мира
Sergey
если нужен внешний мир - да здравствуют интеграционные тесты
Ale
Sergey
именно
Ale
потому что можно сказать, что обычно это тест одного класса
Ale
но это необязательно так
Sergey
я бы к каждому из этих слов добавил "обычно"
для упрощения юнит тесты часто называют просто быстрыми)
Sergey
вот у тебя 10к юнит тестов
Sergey
и какой-то вася додумался заюзать базу у себя в юнит тесте
Sergey
и вместо 5 секунд для прогонки всех тестов, они начинают по минуте выполняться
Ale
вопрос в том, у меня есть единый неделимый юнит репозиторий, за которым и база прячется в том числе, они не имеют смысла один без другого, так почему когда я тестирую этот юнит мне надо его бить?) Чисто философия
Sergey
с точки зрения бизнес логики "репозиторий" это только интерфейс. А реализация это уже инфраструктура. Причем реализация репозитория для SQL будет явно зависеть от SQL
Ale
да
Sergey
и тебе тут явно нужен интеграционный тест что бы проверить как оно "работает вместе"
Sergey
юнит тест не зависит ни от чего
Sergey
с базой не так интересно
Sergey
тут Серега уже сказал про время тестов
Sergey
твой репозиторий существует не просто так. он лежит поверх pdo, dbal, orm, которые тестировали уже за тебя
Sergey
другой менее очевидный критерий
Sergey
вот есть у тебя функция которая зависит от времени
Sergey
и время берется текущее системное
Sergey
это уже ломает изоляцию
Sergey
твой репозиторий существует не просто так. он лежит поверх pdo, dbal, orm, которые тестировали уже за тебя
именно. по этому ты покрываешь только твой код, как твой код взаимодействует с базой данных. Ты не проверяешь корректность работы pdo/dbal
Ale
твой репозиторий существует не просто так. он лежит поверх pdo, dbal, orm, которые тестировали уже за тебя
привязка к языковым конструкциям и взаимодействию с ОС мы почему-то откидываем
Sergey
ты проверяешь только твой интерфейс
Sergey
что объект репозитория соблюдает контракт
Sergey
привязка к языковым конструкциям и взаимодействию с ОС мы почему-то откидываем
взаимодействие с ОС это ты о чем?
Ale
выделение памяти на создаваемые объекты и все такое
Sergey
аа... ну это опять же черный ящик для нас)
Sergey
у тебя есть функции/объекты предоставляющие некий интерфейс
Sergey
и нам "типа" гарантировали что штуки с этим интерфейсом будут работать
Sergey
и тестировать их нам не нужно
Sergey
ну и в целом то что ты описал изолировано в пределах области памяти процесса
Sergey
и не вылазает за него
Sergey
а от того - норм определение юнит теста)
Sergey
юнит тесты - изолированные от внешнего мира тесты
Sergey
это то как я это понимаю
Ale
у тебя юнит это что-то чистое
Ale
чистая функция
Sergey
нууу.... не совсем....
Ale
хотя
Ale
состояние есть
Sergey
если юнит должен вызывать побочные эффекты - ты затыкаешь точки взаимодействия с внешним миром стабами и моками
Ale
внутреннее
Sergey
представь себе черный ящик у которого есть дырки
Sergey
и ты просто в юнит тестах в эти дырки вставляешь заглушки
Sergey
и через них проверяешь эффекты
Ale
если юнит должен вызывать побочные эффекты - ты затыкаешь точки взаимодействия с внешним миром стабами и моками
ну, тут дело в том, что на время тестов мы меняем тип, делая чистой
Sergey
ну тип того)
Ale
или наоборот, из-за состояния в моках\стабах делаем чуть грязнее
Sergey
контролируемые побочные эффекты типа...
Ale
чет мы ушли от изначального вопроса
Sergey
что есть правильно?)