Comments 11
У Битрикс в курсе разработчика есть рекомендации по работе с composer. В чём причина использования своего подхода? Может какие-то несостыковки с рекомендациями.
Если тесты добавляют/изменяют/удаляют записи в базе данных (в т.ч. настройки модулей), то есть механизм отката таких изменений? Или для каждого теста создавать новую базу? Стурктура БД битрикса довольно упоротая, чистить вручную как-то не радует.
У Битрикса в курсах тонны кода и рекомендаций с запашком, и не нужно всё впитывать из этих источников.
По первой части вопроса - подход в курсе рабочий, но (на мой взгляд) противоречит идеологии продукта. Каталог "bitrix" - это штатный функционал CMS. Там находятся базовые модули и компоненты. А свои наработки нужно от него дистанцировать (для того и существует каталог "local").
А по второму вопросу - можно через механизм транзакций. Работает для Oracle, MSSQL, MySQL (для типа таблиц InnoDB). Выглядеть будет примерно так:
SampleTest
<?php
namespace MyProject;
use PHPUnit\Framework\TestCase;
use Bitrix\Main\Application;
use CUser;
class SampleTest extends TestCase
{
public function testDatabaseWriting(): void
{
$email = 'ivanov@microsoft.com';
$connection = Application::getConnection();
$connection->StartTransaction();
$fields = [
'NAME' => 'Сергей',
'LAST_NAME' => 'Иванов',
'EMAIL' => $email,
'LOGIN' => 'ivan',
'LID' => 'ru',
'ACTIVE' => 'Y',
'GROUP_ID' => [1],
'PASSWORD' => '123456',
'CONFIRM_PASSWORD' => '123456'
];
$user = new CUser();
$userId = $user->Add($fields);
$userIdFromDatabase = 0;
$filter = ['EMAIL' => $email];
$dbResult = CUser::GetList(($by='id'), ($order='asc'), $filter);
if ($record = $dbResult->fetch()) {
$userIdFromDatabase = $record['ID'];
}
$connection->rollbackTransaction();
$this->assertEquals($userId, $userIdFromDatabase);
}
}
Если же используются MySQL MyISAM - то тут ничего разумного в голову не приходит. Только руками подчищать.
На сколько я понял, вопрос был не про local, а про то что Битрикс сам использует composer. И вам надо ваш composer смержить с composer битрикса, чтобы вы не получили конфликт версий пересекающихся пакетов.
Более того вы размещаете vendor в публичной части сайта. Кто знает какой пакет вы там затяните, злоумышленник может получить бекдор, через публичный путь сайт.рф/local/vendor/mypackage/backdoor.php
По поводу второй части - действительно, local/vendor имеет смысл закрыть в nginx, либо вовсе выносить vendor за пределы публичной части.
А со штатным composer-bx.json - выглядит он вот так:
composer-bx.json
{
"require-dev": {
"symfony/console": "4.1.*"
}
}
И исходя из документации, используется только ради одного действия из коробки - генерация аннотаций ORM для модулей.
В целом же - да, наверное имеет смысл смержить модулем Composer Merge Plugin, указанным в документации к битриксу.
Вы используете композер, зачем вручную писать автозагрузку?
Инициатива хорошая, но почва неблагодатная.
В свое время не раз наблюдал, как vendor добавляли в git при разработке на cms только по той причине, что для разработки/релизной команды что-то сложнее git pull было уже проблемой. Та небольшая часть команды, которая понимала и использовала composer, вынуждена была также и обслуживать vendor, раскатывая результат для всех через git. Такие вот костыли. Вряд ли с битриксом ситуация лучше: на cms не от хорошей жизни уходят, технический уровень там намного ниже, настолько, что даже composer воспринимается как что-то сложное. Решительно непонятно кто/как будет поддерживать vendor в такой схеме, кроме автора: все упирается в людей, которых придется обучать. Зачастую в необучаемых людей.
Вы слишком драматизируете ситуацию. Предположу что описанному Вами примеру проблемы очень много лет. В настоящее время с множеством курсов и доступностью информации разработчики понимают базовые вещи (git, composer и т.д.).
Технический уровень чаще всего от сложности проекта. Если это типичный интернет-магазин то возможна описанная ситуация с сложностью composer. В таком проекте, если нет своих кастомных модулей, ни к чему использовать phpunit.
Если же проект на подобии какого-либо ЛК для определенного домена знаний, где Битрикс используется как фреймворк и описано много собственной логики - phpunit успешно используется, а команда знает что это за инструмент и как с ним работать. Так и с другими библиотеками обстоят дела.
Используем composer в Битрикс проектах очень давно, и никогда такие проблемы как вы описали не испытывали. Положить vendor в гит такая себе идея. Этим вы убиваете вообще весь смысл использования composer. Потом в добавок будете наблюдать кучу изменений vendor в мержреквестах.
Добрый день! Получили уведомление от Битрикс, что для устранения уязвимостей необходимо обновить до версии 22.0.200, у нас сейчас 21.900.0. В описании обновления нет никакой информации. про устранение уязвимостей. В какой именно версии была эта доработка?
Тестирование в 1C Bitrix