Выборка данных через AOS vs SQL Server

[fed]

Цитата:

Сообщение от mazzy

мы говорим о механизмах доступа к тестируемым данным (как на чтение, так и на запись)
механизмы доступа должны использоваться те же самые, что и у клиентов.


но чего ни в коем случае не должны делать разработчики - придумывать совсем другой механизм доступа к данным!

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ? Что мы проверим - генерацию recid, способность подставлять dataAreaId в записи, работу RLS ? Стоит ли гемор с работой через .net bc, столь скромных результатов ?
Все равно те данные которые мы читаем и пишем имеют мало отношения к реальности и мало чего позволяют оттестировать. Это же юнит-тест, просто ловушка для глупых ляпов. Тупо табличку записали, потом тупо прочитали...
Комплексного тестирования юнит-тесты не заменяют, и смысла из юнит-теста пытаться сделать универсальный тест и для ядра и для .net bc и для злосчастной логистики я не вижу...
Просто по хорошему после юнит-тестов время от времени должен проходить комплексный тест (уже не автоматический), а живыми людми делаемый. И боюсь как раз с этим-то в разработке аксапты и нехорошо....

[mazzy]

Цитата:

Сообщение от fed

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ?

Ты перечитай какие параметры должны учитываться в этом "тупом перенесении данных" и "тупом вынимании"
Выборка данных через AOS vs SQL Server

либо придется генерить кучу наборов данных (во что лично я не верю).
либо использовать таки механизм Аксапты с разные настройками самой Аксапты (хотя бы в вариантах лицензий BE и AM) с одним и тем же набором данных.

Выбор "тупого варианта" автоматически означает, что сильно затруднено тестирование (например, Глобальная адресная книга может быть в вирутальной компании, а может не быть в ней).

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

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