matperez

https://ru.bem.info/

Мое личное мнение - нужно по возможности избегать создания тестовых данных в базе для юнит-тестов и все, что можно сделать заглушками - делать заглушками.
Во-первых, это сильно облегчает и ускоряет тесты;
Во-вторых, цель юнит-тестирования - проверка логики работы метода. В данном случае операции чтения-записи в БД не относятся к функционалу метода, а относятся к функционалу фреймворка. Т.е. такие юнит-тесты по факту тестируют методы фреймворка, в чем как правило нет необходимости.
В-третьих, методы должны тестироваться изолированно. Наличие тестовых данных в БД для теста создает связанность.

Для меня юнит-тесты, в которых много операций с БД, это запашок.

Но если так уж хочется - то можно либо в tearDown вызывать очистку всех созданных данных через deleteAll(), либо пользоваться фикстурами (см ActiveFixture), либо каждый раз загружать дамп базы (см unit.suite.yml)

Это же свойство, оно , если можно так выразиться, - уже реализовано. Т.е. не может быть абстрактным по определению.
PS Это вообще не имеет смысла, так как вся соль в абстракции - описание, без реализации.

Зачем вам учить java ? Судя по вопросу у вас и так жизнь удалась.

Вот же: www.yiiframework.com/doc-2.0/guide-input-file-uplo...

БД - миграциями
Чтобы не мешали - гит и ветки

не давно перешёл на yii1

забудь о нем и переходи на yii2

Лучше всего сначала сделайте сами полностью законченный сайт. Например, визитку с обратной связью и регистрацией. Чтобы хоть что то показывать. Дополнительные языки зависят от ваших предпочтений в разработке

А при чём тут библиотеки? В фреймворках есть механизм событий, его и используйте.
Пользователь нажал «Удалить фотографию», вы в контроллере это действие выполняете и генерируете событие (или в обратном порядке). Дальше обработчик-подписчик ловит это событие и выполняет какое-то действие — рассылает уведомления, пишет логи и т.д. На одно событие может быть неограниченной число обработчиков, что даёт гибкость — не надо зашивать весь код в одном месте.

Ага.
Пусть еще тему по мотивам хохломы сделают, с медведями и балалайками.

с хохломой в следующем релизе )


А если серьезно, то это прост никому не нужно.

Удобство выражается в наличии стандартного решения практически на все случаи жизни с хорошей документацией. За счет, как вы уже подметили: конвенции, гемов и стандартного воркфлоу (генераторы, ассеты, деплой, миграции, консоль...)

Но, конечно, нужно понимать, что каждый инструмент - для своей задачи. Бложик делайте на пхп, систему складского учета - на джаве, распознавание лиц в академических целях - на питоне, в промышленных - на плюсах.

А все эти вещи про символы, строки и синтаксис - это все несущественная фигня.

Хотите увидеть удобство рельс ? Найдите стартап с инвестициями и гибкими требованиями на начальной стадии, где нужна существенная работа на бэкэнде и фронтэнде одновременно.