1 Отредактировано dmitryk (2015-04-16 22:02:55)

Тема: Доктрина 2.5.0

Сегодня переводил проект на доктрину 2.5 с версии 2.4.7. В проекте 160 000 строк кода* в папке src/ не учитывая конфиги, темплейты и прочее.

Так вот. Все работает** :)

Думаю те, у кого проекты поменьше могут смело переезжать.

*Проект на 60% покрыт юнит тестами и функциональными тоже.
**Отвалился бандл FOSElasticaBundle но временно залеплен костылем, пока идут разбирательства в трекере доктрины.

2

Re: Доктрина 2.5.0

dmitryk пишет:

Сегодня переводил проект на доктрину 2.5 с версии 2.4.7. В проекте 160 000 строк кода
Проект на 60% покрыт юнит тестами и функциональными тоже
Все работает

Если следовать логике, то 40% кода тестами не покрыто. Следовательно, эту функциональность нужно тестировать вручную. Менее чем за сутки проверили работу ~65000 строк кода? default/smile

В проекте на 160к строк кода, даже со 100% покрытием тестами, я бы не был в чем-либо уверен не то, что за сутки, а даже за неделю. default/smile Потому что тесты тоже пишут люди, они тоже могут быть с ошибками, плюс 100%-е покрытие тестами для чего-либо достаточно сложного практически недостижимо.
Т.е. определить, упало все или нет — это просто. А вот выявить сайд-эффекты и баги — бывает, месяцы уходят.

Т.е. то, что все работает — это клево и радует. Но для приведенных цифр оценка слишком оптимистична. default/smile

P.S. В деве гоняю 2.5.0, два дня назад нарвался на странный глюк — коллекция, собираемая через indexBy, где индексом служит один из идентификаторов составного ключа. При получении объекта по ключу коллекция возвращала объект, принадлежащий другому идентификатору составного ключа. Т.е. грубо говоря, я запрашивал один объект, а получал другой.
Разбираться времени не было (дедлайн), пока забил и обошел проблему другим путем.

3

Re: Доктрина 2.5.0

На самом деле, 60% если приложить к реальным проектам - то это огромная цифра. Сужу по своей практике, и по тому, что и где видел.

В абсолютных значениях конечно да, 40% получается осталось не покрыто тестами. Но я не унываю т.к.

1) Оно не в продакшене, и до сих пор тестируется и есть время еще что-то выловить
3) У нас строго запрещено делать с доктриной что-то особенное. Поэтому наш код "не влетел" ни на один BC-break заявленный авторами.

Re: Доктрина 2.5.0

~ 100к строк кода
Процент покрытия кода Unit-тестами: 99.5%
+ Автотесты еще, которые покрывают отдельно API, отдельно UI.

Переход на 2.5 как-то очень даже быстро прошел, косяков не вылезло. Вот переход на Symfony 2.7 с новой пачкой deprecation-ов для нас будет более тяжелым. Самое первое, что бросается в глаза, это в Form-ах переписывать setDefaultOptions на configureOptions.

Re: Доктрина 2.5.0

@relo_san

С коллекциями на 2.4 можно было поймать тоже интересности. Метод initialize() у PersistentCollection не всегда иницализировал коллекцию. Ловили несколько раз: если вызываешь метод toArray, то возвращался далеко не полный массив с данными, а если их перебираешь foreach-ем - все было ок. Вот с переходом на 2.5 такой штуки еще не наблюдал.

6

Re: Доктрина 2.5.0

dmitryk пишет:

На самом деле, 60% если приложить к реальным проектам - то это огромная цифра.

С этим я не спорил, даже не пытался. Хотя, среди больших проектов покрытие тестами более распространено (это просто иногда единственный способ для проекта выжить, особенно когда над ним работает много людей), но процент покрытия, когда оно вообще есть, обычно низкий.

Я сейчас покрываю тестами только ключевые вещи — просто потому что над проектом работаю один и обычно без тестов знаю, что и где поломается в случае изменения чего-либо. Плюс, фанатично слежу за точным описанием синопсиса в PHPDoc'ах, в связи с чем о большинстве проблем мне сразу сообщает IDE. Придерживаюсь подхода «не ломать». Но по большому счету, на написание тестов просто нет времени, разве что еще кого-то в проект брать. Их наличие в любом случае не помешало бы проекту, но пока соотношение затраченного на написание тестов времени и профита от них не в пользу последних.

daemon_master пишет:

Form-ах переписывать setDefaultOptions на configureOptions

Формы вообще эпичны. Тот же OptionsResolverInterface, который депрекейтед и раздражает, но избавиться от него в текущей версии способов нет, так как AbstractType хочет именно его.