ЮW
Size: a a a
2021 October 05
SP
условно на соотношение "количество строк кода относящиеся к установке прекондишенов и количество строк на сам тест"
SP
ты просил фидбэк а теперь обижаешься)
МФ
а ты ссылаешься на размытую декларацию темринов, не вчитываясь в смысл (в книгах) и сути зачем и почему так или иначе стоит делать
SP
тип если соотношение больше походит на 50/50 или больше прекондишен нежели тест - есть потенциально проблемы со связанностью. Опять же это не значит что "проблема точно есть" но туда интересно глянуть и разобраться почему так
SP
"типизайия" или
$this->$methodName()?SP
https://github.com/WalkWeb/Battle-Module/blob/master/tests/Battle/Result/Statistics/StatisticsTest.php#L96 - имена тест кейсов непонятные, не понятно что проверяют, судя по виду в рамках одного тест кейса проверяется больше одной вещи...
SP
можно короч на тему integrational (integrated) tests are a scam" почитать, тут как раз они родимые
SP
ну я ж говорю - я код смэлы перечисляю которые вижу. Есть там проблема или это неплохое решение - для этого надо детально смотреть. Но в 90% ситуаций это будет выстрел в ногу. МОжет быть это некий конвеншен который ты на уровне проекта определяешь и тогда ты от рисков защитился но "обычно нет"
SP
я про юниты. в e2e/приемочных у тебя есть такая вещь как "test data management" которая намекает что все сложно. Да и приемочных и e2e потому много не стоит делать и только на позитивные флоу.
SP
а вот в юнихах когда у тебя прекондишен выставляется для тестов (зависимости и их стэйт) на пол теста и больше - это сигнальчик что слишком много зависимостей. Иногда это ок, иногда нет, сигнальчик. надо присматриваться к такому
SP
когда соотношение 10 к 1 в юнитах на arrange то явно есть проблемы
SP
я о части где сборка зависимостей - значит высокая связанность и много зависимостей.
SP
вот вся эта концепция whole value - считай чистые функции где вся логика и нет внешних зависимостей