class AccountSpec extends ObjectBehavior { function it_changes_unconfirmed_balance() { $this->shouldNotThrow()->duringAddUnconfirmedBalance(100); $this->shouldNotThrow()->duringAddUnconfirmedBalance(-20); $this->unconfirmedBalance()->shouldReturn('80'); }

я хз, я всю жизнь писал на xUnit, поэтому спеки для меня даже выглядят дико

как тестировать конструирование объекта в phpunit? я правильно понимаю что если ты хочешь это потестить тебе уже не получится юзать setUp?

или setUp не будет ничего полезного делать?

в смысле тестить конструирование?

что это за тест такой?

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

в phpspec я могу написать что-то типа

ок, щас

$this->beConstructedWith($foo, $bar); $this->shouldThrow()->duringInstantiation();

хотя ладно кейс с setUp будет таким же и в спеке

там просто это называется let

public function testShitstorm() { $this->expectException(\InvalidArgumentException::class); new \Calculator('omfg'); }

или же

/** * @expectedException \InvalidArgumentException */ public function testShitstorm() { new \Calculator('omfg'); }

https://inviqa.com/blog/my-top-ten-favourite-phpspec-limitations

You can't have code coverage серьезно?

I can't use a data provider

:O

из коробки - не сможешь, но можно поставить экстеншен

дата провайдеров тоже нет

I can't mock abstract methods - а интерфейсы можешь?

НО

вопервых возможно что-то такое сейчас должно появиться в новых релизах ну и опять же есть экстеншены

а несколько интерфейсов одновременно?)

I can't mock abstract methods - а интерфейсы можешь?

могу

а несколько интерфейсов одновременно?)

а тебе надо несколько интерфейсов одновременно?)

да, были такие кейсы

на одной зависимости

да, были такие кейсы

а ты считаешь что это нормально?)

а почему нет?)

ну как тебе сказать... как минимум звучит странно

быть может это должен быть не 2 интерфейса а один?

может ты не так разделил интерфейсы?

может твой класс делает что-то слишком много?

не, именно 2 надо было, один как маркер вроде был

щас по коду поищу где это было

не, именно 2 надо было, один как маркер вроде был

если это два разных объекта (пусть один и тот же просто две зависимости) то норм, но тут тебе phpspec норм

иначе что-то не так с сегрегацией интерфейсов

а да вот нашел. там коллекция, в нее добавляются элементы интерфейса Filter, но у некоторых элементов может быть еще интерфейс StatefulFilter и вот надо было проверить метод который делает getStatefulFilters

а да вот нашел. там коллекция, в нее добавляются элементы интерфейса Filter, но у некоторых элементов может быть еще интерфейс StatefulFilter и вот надо было проверить метод который делает getStatefulFilters

то есть у тебя inscenceof там7

да

ну... чувствуешь запашек легкий?

та не, норм

ну это не вонь, это так... как если ты открываешь холодильник и тебе не комфортно

ок, твой вариант)

я ж задачу не знаю)

чем отличается поведение StetefulFilter от Filter и что ты делаешь внутри коллекции?

class Filters { /** * @var FilterInterface[] */ private $filters = []; /** * @return FilterInterface[] */ public function getFilters() { return $this->filters; } /** * @param FilterInterface $filter */ public function addFilter(FilterInterface $filter) { $this->filters[get_class($filter)] = $filter; } /** * @param string[] $names * @return FilterInterface[] */ public function getFiltersExcept(...$names) { $filters = $this->filters; foreach ($names as $name) { if (!isset($filters[$name])) { continue; } unset($filters[$name]); } return $filters; } /** * @param $name * @return FilterInterface */ public function getFilter($name) { return $this->filters[$name]; } /** * @return StatefulFilterInterface[] */ public function getStatefulFilters() { $filters = []; foreach ($this->filters as $key => $filter) { if ($filter instanceof StatefulFilterInterface) { $filters[$key] = $filter; } } return $filters; } }

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

getStatefulFilters

только там вижу inscenceof

и не понимаю зачем этот метод

ну вот надо)

ну вот запах

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

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

то проблемы быстрее находятся

вот где он юзается public function createSearchRequest($searchParams) { $searchRequest = new SearchRequest(); $searchRequest->setSearchParams($searchParams); foreach ($this->filtersProvider->getStatefulFilters() as $filter) { $searchRequest->addFilterContext(get_class($filter), $filter->createContext($searchRequest)); } return $searchRequest; }

так почему бы тебе для stateful фильтров не завести тупо отдельную коллекцию?

зачем?)

избавился бы от ифов

ну это ж разные интерфейсы

и разные штуки

если бы у тебя были дженерики

то тебе нужно было бы что-то в духе

Filters<Filter|StatefulFilter>

не. просто StatefulFilter не может сам существовать

только как маркер для Filter

поэтому List<Filter>

...хз стремная хрень

короч я хз... сча попробую переписать свои тест кейсы под phpunit и посмотреть насколько тошнотворно

если это стремная хрень, зачем ее добавляют в core lib котлина?

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/filter-is-instance.html

filters.filterIsInstance<StatefulFilter>() вот так бы этот метод выглядел

нуууу... хз)

компромисы?)

😃 да нет, у меня подобные кейсы есть еще в других местах

когда есть пачка провайдеров, но все умеют разное. мне нужно выбрать по маркеру их

точнее там не маркеры, а полноценные интерфейсы

Про котлин был кстати годный доклад, о том, что любой язык — сполшные компромисы, ну и примеры компромисов, которые они приняли.