https://3v4l.org/cik4l

Есть тест для логера. Логер что-то там пишет в файл. Иногда тесты валятся потому что в логе [Sun, 27 Nov 16 17:03:46 +0000][DEBUG] Hello а мы ожидаем [Sun, 27 Nov 16 17:03:45 +0000][DEBUG] Hello не всегда такое, но бывает. учитывая факт что тестов становится все больше и больше, тестовый енв становится все тормознутей, предполагаю что подобные фейлы будут проявляться чаще; да и оно может случатся когда лог пишется на границе секунд например. подкиньте идею, какой нибудь не заморочливый способ тестировать это дело. я в том плане чтоб тест не превратился по сложности в трудно понятный код. $logger->log($level, 'Hello'); $logger->close(); $I->amInPath($this->logPath); $I->openFile($fileName); $expected = sprintf( "[%s][%s] Hello", date('D, d M y H:i:s O'), $name ); $I->seeInThisFile($expected); // фейлится тут

> подкиньте идею, какой нибудь не заморочливый способ тестировать это дело регуляркой?

вместо строк

как вариант да, думал

ну что бы не завязываться на конкретных данных зависящих от времени

а прочерять что-то типа

если ничего не придумаю - буду регуляркой

а что тут еще можно придумать? мокать время? так себе идея

[TIMESTAMP][DEBUG] Hello

а потом тупо preg_quote + str_replace

угу

что бы было красивенько

еще клевая штука

интеграционные тесты которые проверяют что мы вообще умеем писать в файл правильно

и юнит тесты которые проверяют что именно мы пишем

это было бы грамотнее

в интеграционных тестах проверять тупо наличие строк, а не их содержимое

$writer->write(sprintf('[%s][%s] %s'), $timestamp, $level, $message));

и в юнит тестах мокать $writer

а интеграционными покрывать что он вообще может писать

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

в случаях с фс они выглядят одинаково сложно

да, все никак не соберусь это дело разделить. там частично намешано конечно интеграционных и юнит. но тестов > 1k и так-то они рабочие, просто не православные ) по этому я на них смотрю, вздыхаю, и откладываю эту идею на потом

> в случаях с фс они выглядят одинаково сложно интеграционным тестам райтера нужно проверить только то, в каком порядке чего записалось, не затерлось ли, проверить стримы и т.д

ну и отдельный бонус - можно потом будет делать отдельные райтеры

например в syslog

а не в файл

или в memry stream

хотя хер его знает

я логгеры никогда не писал)

я понимаю про что ты, DIP там, все дела

абстрактные врайтеры

скорее SRP и сегрегация интерфейсов

нада в монолог посомотреть еще

как ребята тестируют

у них писатели отдельно и форматтеры отдельно

насколько я помню

скорее SRP и сегрегация интерфейсов

оно все связано))

оно все связано))

ну тип того)

S

S - Про то, как делить на части исходя из возможных изменений O - Про то, как расширять функционал не внося изменений в код L - Про то, как грамотно строить абстракции и предотвращать несовместимые интерфейсы I - Про то, как уменьшить связанность и добиться тотального контроля за тем, кто что юзает и кому что на самом деле надо D - Про то, как обезапасить одни модули от изменений в других модулях

в общем и целом SOLID это про protected variations из GRASP

или как сделать так что бы "работает не трогай, особенно если на это что-то завязан кто-то другой"

форматеры и у меня отдельно

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

спасибо Серый

Мне кажется или вы работаете в телеграме? Постоянно онлайн :)

@fes0r особенно

:)

достаточно просто не выключать ноут

и ты всегда будешь онлайн

с телефоном еще проще

:)

воскресенье ж

Как давно у вас отключали электричество ?

Сорри что оффтоп

настолько татально что не можешь уже телефон зарядить?

хм...

вот если прям сейчас у меня вырубят свет

ноут проживет еще часоов 7-8

У меня уже ноут тютю

телефон можно подключить и тоже чутка подзарядить

:)

а еще... могу пожервтвовать батареей электронки и ими заряжать телефон

и прожить так еще часиков 8

power bank же

ERROR: S client not available

вот все знают что null это плохо и вместо $user = $this->userRepository->find(1); if(null === $user){ .... } должно быть try{ $user = $this->userRepository->find(1); }catch($e){...} но мне одному кажется что это как-то некрасиво чтоли выходит?)

я делаю так

``` interface UserRepository { public function get(int $user): User; public function find(int $user): ?User; }

хотя сейчас задумался

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

хм....

хм........

ну да

try catch норм

try { $user = $users->get(42); } catch (UserNotFoundException $e) { $user = null; }

пожалуй перестану делать нулабл методы в репозиториях

пока за минуту не нагенерю "зачем"

а у тебя есть UserRepository::has ?

уверен, что если нужен

то есть)

тогда find ?User не нужен

не думаю, что это так вот прямо связано

думаю что репозиторий это коллекция, которой find не нужен если есть has

вот ща совсем не понял

http://shawnmc.cool/the-repository-pattern

ну например

ну я знаю, что такое репозиторий, лол)

у репозитория(коллекции) не может быть метода save

может

ты заголовок наверное прочел и закрыл

нет, полистал еще

ну вот в конце он чето про add написал

короче как has может избавить от find?

я к тому что у любой коллекции есть метод поиска

если есть has то использовать find просто чтоб поискать излишне

эм

что делает has, а то я кажется совсем перестаю понимать