Вот и когда все в такой напряженке, тесты не протолкнешь; потому что все что нужно === рабочий прототип, на который дадут(или нет) деньги;

10%

покрой важные штуки тестами

100% покрытие не нужно

важный вопрос code coverage

10%

конечно, я же сужу с своей колокольни, у меня опыта не так много;

должен ли он быть 100%

важный вопрос code coverage

бесполезная метрика) намного более полезная - количество регрессий на количество изменений)

и дает ли он гарантию что при наличие 100% проблем не будет ?)

должен ли он быть 100%

100% покрытие кода тестами не гарантирует отсутствия багов

бесполезная метрика) намного более полезная - количество регрессий на количество изменений)

согласен, просто я по популярной метрике иду)

100% покрытие кода тестами не гарантирует отсутствия багов

именно )

я к этому и клонил)

НО, покрытие кода может давать тебе представление о том что покрыто а что нет

ну то есть 100% не нужно, но хотя бы 80-90 стремиться стоит

поэтому понимание этих метрик приходит с опытом

и зависит от проекта или заказчиков

ну в целом от уровня страха

ну и оплаты)

если тебе сыкатно лесть в этот модуль - значит мало тестов

если не сыкатно - значит норм

не ну есть конечно психи которым никогда не сыкатно

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

ладно срач хорош пойду доку делать )

пойду тесты писать

кстате

посмотреть либу снова нет желания ?

по psr/container implementation ?

не

)

ок

:D

я сделал лучше)

верю но с этим срачем я исчерпал свой лимит на "потрынденть"

ок

круто когда ты самоорганизованный, наверное

наверное)

но это не про меня)

значит не про меня и подавно)

https://t.me/socionika_alignment вот чат. заходите. все без бан и прочего

зачем? )

жалко я ливал и у меня права снялись

шо за пиздец вася)

@fes0r @f3ath потрите может спам?

Может они заинтересованы в нём )

Может они заинтересованы в нём )

теория заговора?)

весь этот чатик нужен был только ради того, чтобы пропиарить какую-то слабенькую флудилку)

теория заговора?)

Нет, банальная коммерция

весь этот чатик нужен был только ради того, чтобы пропиарить какую-то слабенькую флудилку)

серьезно?

@f3ath @fes0r 4 messages deleted, reason: spam

Нет, банальная коммерция

да ну, мы ж тут простите в it, зарабатываем(те кто в снг) в разы больше средней. Минута работы будет дороже такой коммерции)

Sergei @f3ath в линки групп можно добавить @frp_ru

эээээ я дальше "удалить сообщение со спамом" не обучен

видимо это только коняка может, как владелец

вероятно

давайте призовем

@ployd а ты где еще сидишь? вроде в чатике ноды тебя видел, а в frp не видел

@ployd а ты где еще сидишь? вроде в чатике ноды тебя видел, а в frp не видел

Ну из публичных в rust-е и в паре data science чатиках.

frp это про реактивщину?

там в основном про ramda в js )

Ну, хоть что-то

Sergei @f3ath в линки групп можно добавить @frp_ru

Добавиль

давайте срач по LSP

<?php class Order { protected $items = []; public function addItem(Item $item) { $this->items[] = $item; } public function getItems() { return $this->items; } } class FreeOrder extends Order { public function addItem(Item $item) { if ($item->price() !== 0) { throw new Exception(); } $this->items[] = $item; } } class OrderCollector { public function сollect(Order $order, $items) { foreach ($items as $item) { $order->addItem($item); } } } FreeOrder нарушает LSP тем что бросает эксепшен и тем самым делает "неожиданные" вещи, или это ок?

Так методы разные

Или я туплю?)

ERROR: S client not available

это унаследованный метод, там вообще вызов к паренту должен быть

тьфу)

<?php class Order { protected $items = []; public function addItem(Item $item) { $this->items[] = $item; } public function getItems() { return $this->items; } } class FreeOrder extends Order { public function addItem(Item $item) { if ($item->price() !== 0) { throw new Exception(); } $this->items[] = $item; } } class OrderCollector { public function сollect(Order $order, $items) { foreach ($items as $item) { $order->addItem($item); } } } FreeOrder нарушает LSP тем что бросает эксепшен и тем самым делает "неожиданные" вещи, или это ок?

да, нарушает

<?php class Order { protected $items = []; public function addItem(Item $item) { $this->items[] = $item; } public function getItems() { return $this->items; } } class FreeOrder extends Order { public function addItem(Item $item) { if ($item->price() !== 0) { throw new Exception(); } $this->items[] = $item; } } class OrderCollector { public function сollect(Order $order, $items) { foreach ($items as $item) { $order->addItem($item); } } } FreeOrder нарушает LSP тем что бросает эксепшен и тем самым делает "неожиданные" вещи, или это ок?

Есть же ГИСТ!

код не сложный, можно и без гиста прочитать)

Есть же ГИСТ!

ну давай еще и здесь срачик на эту тему)

это унаследованный метод, там вообще вызов к паренту должен быть

не обязательно

да, нарушает

чем нарушает?

чем нарушает?

ты же и описал, вместо ожидаемого добавления пользователю Order произойдет exception

не обязательно

ну необязательно, если имплементация принципиально отличается

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

в большинстве случаев

ну необязательно, если имплементация принципиально отличается

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

окей. в принципе сказано о подтипах определенного типа. интерфейсы как известно являются типами так вот теперь если мы уберем наследование и сделаем с интерфейсами, мы по прежнему нарушаем LSP?) @mkusher <?php class OrderInterface { public function addItem(Item $item); public function getItems(); } class Order implements OrderInterface { protected $items = []; public function addItem(Item $item) { $this->items[] = $item; } public function getItems() { return $this->items; } } class FreeOrder implements OrderInterface { public function addItem(Item $item) { if ($item->price() !== 0) { throw new Exception(); } $this->items[] = $item; } public function getItems() { return $this->items; } }

и если мы в первом варианте заменить эксепшен на return?

окей. в принципе сказано о подтипах определенного типа. интерфейсы как известно являются типами так вот теперь если мы уберем наследование и сделаем с интерфейсами, мы по прежнему нарушаем LSP?) @mkusher <?php class OrderInterface { public function addItem(Item $item); public function getItems(); } class Order implements OrderInterface { protected $items = []; public function addItem(Item $item) { $this->items[] = $item; } public function getItems() { return $this->items; } } class FreeOrder implements OrderInterface { public function addItem(Item $item) { if ($item->price() !== 0) { throw new Exception(); } $this->items[] = $item; } public function getItems() { return $this->items; } }

вопрос в контракте, который стоит за интерфейсом

интерефейс не определяет никаких эксепшенов. точно так же как и в переопределенном методе нигде не описаны эксепшены

банальный пример interface List<T> { add(item: T): void; remove(item: T): void; has(item: T): void; length(): number; } банальный примеры контракта, которые в типе описать нельзя здесь: list.add(a); expect(list.has(a)).to.be.true; или list.add(a); expect(list.length()).to.be(1);

тогда некий class DoubleList который делает вместо add add(item: T) { this.internal.push(item); this.internal.push(item); } нарушит этот контракт, потому что длина изменилась не на один, а на два

потому весь вопрос в том, чего ты от интерфейса ждешь)

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

ну как-то так

ну со спекой притянуто за уши

?

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

у меня может быть интерфейс для кеша, и реализации типа Void, Array, Memcached

думаю да, может быть

тогда некий class DoubleList который делает вместо add add(item: T) { this.internal.push(item); this.internal.push(item); } нарушит этот контракт, потому что длина изменилась не на один, а на два

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

и закрывать глаза на разные имплементации интерфейса

ничего не понял

в смысле