dev400

В Yii даже банальное ... порождает запрос к базе данных, для получения структуры таблицы news.

Смокать вполне реально. Не знаю, как через Mockery, но через PHPUnit у меня вполне получалось.

В шаблонах yii2-advanced и yii2-basic есть unit, functional, acceptance. Стоит выделить отдельную группу тестов - integration?

Это название означает, что тесты не строго модульные. Реализованы они могут быть тем же PHPUnit.

integration==functional

Нет. integration = тестирует реальную базу, но всё ещё в терминах кода. functional = тестирует в терминах конечного пользователя: страницы, URL-ы, парсинг тела ответа. При этом реальный браузер не запускается. acceptance = то же, но с реальным браузером.

Есть свои плюсы но минусы их перекрывают с оооочень большой лихвой.
Искать что либо сложно. Без поиска по проекту в IDE найти что то куче файлов руками не реально.
Интересности можно найти -> dev.1c-bitrix.ru/community/blogs + google и yandex в поиск.
Так же я пришел к выводу что "сношать" их саппорт - норма жизни :(
В целом начните с их доки - она ужасна но "зеленное представление" даст. Например dev.1c-bitrix.ru/learning/course/index.php?COURSE_...
Оч советую разобраться как работает их кэш. Без него что либо с приемлемой скоростью работать не будет.
Ну и в целом советую запастись успокоительным и забыть все что вы слышали до этого про нормальные фреймворки, стандарты PSR, паттерны.

P.S. Реализовали несколько проектов на Битрикс (от "сайтиков" до магазинов в т.ч. интеграция с 1С (не стандартная) и с их CRM как облачной так и коробочной, всякие кастомные штуки аля мега хитрых мультицен и отчетов, писали свои модули).

https://github.com/adriengibrat/torrent-rw
https://github.com/christeredvartsen/php-bittorrent

Подключайте как можно больше каналов в любом случае,нельзя судить что хорошо,а что плохо,не проанализировав конкретный канал. Если у вас уникальный и интересный контент и вам есть о чем сообщить вашей аудитории - подключайте все
-одноклассники
-фейсбук
-вконтакте
-youtube
-GOOGLE+
-инстаграм
-твиттер
-телеграмм
-емейл рассылки
-mytarget и .д.
Как именно она будет проявляться?-количеством переходов на ваш сайт с того или иного ресурса ну и дальнейшей конверсией.
Настройте яндекс метрику,гугл аналитикс,проставьте цели и не забывайте про utm метки.
И снимайте аналитику через некоторое время. Так же почитайте информацию об интеграции сервисов типа твитер-фейсбук(пишите в 1 месте-а это все дублируется в несколько ресурсов)

Конечно нужно изначально примерно понимать кто ваша ЦА. Если вы продаете резинки для браслетов,которые сейчас очень популярны в младших классах-про "одноклассники" можно забыть,ну и наоборот-циркониевый браслет не будет интересен в телеграмме. Тоже самое касается и услуг

$params["image_url"] = (isset($array['image_url']) ? $array['image_url'] : NULL);

UPDATE ... `image_url` = IFNULL(:image_url, `image_url`) ...

$params = [
                "id" => $array['category_id'],
                "cat_name" => $array['category_name'],
                "cat_url" => $array['category_url'],
                "image_url" => $array['image_url'],
                "parent_cat" => $array['parent_cat'],
            ];
if ($image) {
    $params["image_url"] = $image;
}

Посмотрите мои сценарии, может поможет.

Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.

вы должны проверять корректность работы системы. Всего-то. Причем с оглядкой не только на "сейчас" (тут мы и руками можем проверить быстро) но еще с оглядкой на будущее. Если вы планируете этот код выкинуть - тестировать его нет смысла. Вы на автоматизацию тестирования убьете больше времени чем проверите руками.

С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.

Далее уже все зависит от сложности тестирования. По хорошему наши тесты должны быть маленькие и, главное, ничего не знать о деталях реализации. Скажем вы хотите проверить что система корректно добавляет новости. Самый простой способ это проверить - создать новость и проверить что не вернулись ошибки. Для этого можно составить HTTP запрос и получить HTTP ответ. Максимально просто.

Но такой тест отрабатывает относительно долго. Представьте себе что вы пишите что-то посложнее. И у вас уже 100 различных тестовых сценариев для одого кусочка системы. В итоге этот маленький кусочек будет тестироваться больше минуты, и мы успеем заскучать. Для того что бы упростить - мы дробим этот кусочек еще и еще пока не находятся такие куски, которые мы можем проверить удобно и быстро. Например если вопрос в корректности валидации данных - мы можем тестировать только контроллер, а если вопрос в каких-то бизнес правилах отдельных - мы можем и их отдельно вынести и тестировать. Это будут интеграционные тесты.

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

Ну и опять же, дробление вниз должно происходить с целью упрощения тестирования и разработки, а не просто так. Потому например никто не покрывает юнит тестами вещи, которые работают например с базой данных. Слишком дорого в поддержке. С точки зрения тестов все должно быть по большому счету похоже на черный ящик. Вы что-то хотите от ящика и проверяете делает ли он это. Как только тесты становятся завязаны на реализацию - тесты начинают приносить боль.

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

Здесь нужно тестировать два важных момента:
1. Насколько корректно работает валидация данных в контроллере? (кода валидации здесь не преведено)
2. Насколько стабильно отрабатывается непосредственно добавление материалов в БД при параллельных запросах, высокой нагрузке и одинаковых материалах? (проверка стабильности соединения с БД под нагрузкой и проверка отсутствия ложных срабатываний исключений, а при их наличии - корректная дальнейшая обработка)

Ответ прост: читайте требования ПС к сайтам и выполняйте их по-максимуму.

Основные:
1. Валидная разметка HTML4(5)
2. Страницы без переадресаций (возврат контента с кодом 200 при запросе).
3. META и обычные тэги: title, description, keywords, H1, H2, H3, p
4. sitemap.xml + robots.txt
5. Все визуальные элементы, ведущие на другую страницу, должны иметь линк href даже тогда, когда они обрабатываются через JS.

Неосновные:
1. Микроразметка (желательно сразу все 3 схемы, см. требования ПС)
2. META-тэги соц.сетей, авторства, рейтинга материала и прочего.
3. RSS/ATOM
4. BackPing (оповещение ПС о новых материалах на сайте)
5. Корректные настройки языка страниц и канонических урлов (при необходимости).

Просто сделайте запрос в Гугле: Ubuntu LEMP.
Лично мне помог туториал от DigitalOcean.

в куки конечно имхо... ведь тут подделывать нечего ))))) просто инфа и не более того

Есть какой то обучающий мануал, в котором коротко и доступно изложена настройка сервера с нуля?

Нет.
Т.к. конфигурация ОС и конфигурация модулей ОС и ПО - у всех уникальна.
Поэтому, есть отдельные мануалы по настройке каждого компонента на сайтах их производителей: отдельно установка ОС, отдельно апач, отдельно nginx и т.д.

Склоняюсь к тому, что в сессиях нужно хранить что-то важное и ценное, а в cookie всё остальное :)
Cookie легко редактируются, а с сессиями такое проделать нельзя.

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

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

достаточно проставить регион в консоли гугла/яндекса.
если считаете, что этого мало, нужно не ждать и действовать решительней, можете добавить в заголовок еще и геотеги как вот тут
www.geo-tag.de/generator/en.html
но поисковики их игнорируют.