Тестирование в 1C Bitrix

[DyoMin]

У Битрикс в курсе разработчика есть рекомендации по работе с composer. В чём причина использования своего подхода? Может какие-то несостыковки с рекомендациями.

Если тесты добавляют/изменяют/удаляют записи в базе данных (в т.ч. настройки модулей), то есть механизм отката таких изменений? Или для каждого теста создавать новую базу? Стурктура БД битрикса довольно упоротая, чистить вручную как-то не радует.

[topuserman]

У Битрикса в курсах тонны кода и рекомендаций с запашком, и не нужно всё впитывать из этих источников.

[undersunn]

По первой части вопроса - подход в курсе рабочий, но (на мой взгляд) противоречит идеологии продукта. Каталог "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 = '[e-mail]';

		$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 - то тут ничего разумного в голову не приходит. Только руками подчищать.

[k0rinf]

На сколько я понял, вопрос был не про local, а про то что Битрикс сам использует composer. И вам надо ваш composer смержить с composer битрикса, чтобы вы не получили конфликт версий пересекающихся пакетов.

Более того вы размещаете vendor в публичной части сайта. Кто знает какой пакет вы там затяните, злоумышленник может получить бекдор, через публичный путь сайт.рф/local/vendor/mypackage/backdoor.php

[undersunn]

По поводу второй части - действительно, local/vendor имеет смысл закрыть в nginx, либо вовсе выносить vendor за пределы публичной части.

А со штатным composer-bx.json - выглядит он вот так:

composer-bx.json

{
  "require-dev": {
    "symfony/console": "4.1.*"
  }
}

И исходя из документации, используется только ради одного действия из коробки - генерация аннотаций ORM для модулей.
В целом же - да, наверное имеет смысл смержить модулем Composer Merge Plugin, указанным в документации к битриксу.

[topuserman]

Вы используете композер, зачем вручную писать автозагрузку?

[undersunn]

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

[0x131315]

Инициатива хорошая, но почва неблагодатная.

В свое время не раз наблюдал, как vendor добавляли в git при разработке на cms только по той причине, что для разработки/релизной команды что-то сложнее git pull было уже проблемой. Та небольшая часть команды, которая понимала и использовала composer, вынуждена была также и обслуживать vendor, раскатывая результат для всех через git. Такие вот костыли. Вряд ли с битриксом ситуация лучше: на cms не от хорошей жизни уходят, технический уровень там намного ниже, настолько, что даже composer воспринимается как что-то сложное. Решительно непонятно кто/как будет поддерживать vendor в такой схеме, кроме автора: все упирается в людей, которых придется обучать. Зачастую в необучаемых людей.

[Atton]

Вы слишком драматизируете ситуацию. Предположу что описанному Вами примеру проблемы очень много лет. В настоящее время с множеством курсов и доступностью информации разработчики понимают базовые вещи (git, composer и т.д.).

Технический уровень чаще всего от сложности проекта. Если это типичный интернет-магазин то возможна описанная ситуация с сложностью composer. В таком проекте, если нет своих кастомных модулей, ни к чему использовать phpunit.

Если же проект на подобии какого-либо ЛК для определенного домена знаний, где Битрикс используется как фреймворк и описано много собственной логики - phpunit успешно используется, а команда знает что это за инструмент и как с ним работать. Так и с другими библиотеками обстоят дела.

[k0rinf]

Используем composer в Битрикс проектах очень давно, и никогда такие проблемы как вы описали не испытывали. Положить vendor в гит такая себе идея. Этим вы убиваете вообще весь смысл использования composer. Потом в добавок будете наблюдать кучу изменений vendor в мержреквестах.

[Myfos]

Добрый день! Получили уведомление от Битрикс, что для устранения уязвимостей необходимо обновить до версии 22.0.200, у нас сейчас 21.900.0. В описании обновления нет никакой информации. про устранение уязвимостей. В какой именно версии была эта доработка?