Вот, задумал свою нетленку написать. С нуля. И всякие мне мысли в голову лезут про MVC, про юнит тестирование и прочие правильные вещи.
По сути надо разделять функции обработки данных , функции записи, и функции чтения данных. Что бы можно было протестировать отдельно стоящую функцию "рассчитать ндс по строке" данные в нее должны поступать параметрами, и не вытягиваться из базы (например ставка ндс по справочнику, ставок ндс), и  так далее. Кто занимался подобными вещами, поделитесь опытом, как разделяли модули, стремились ли функции сделать "чистыми" (не зависящими от состояния БД, а только оь входных параметров), и т.д.

Сюда https://gitter.im/xDrivenDevelopment/xUnitFor1C
и сюда https://gitter.im/silverbulleters/vanessa-behavior

там лучше объяснят

(1) Ни прибавить, ни отнять.

еще есть вот: http://test1c.com/

(0) эти все влажные мечты разобьются об требования к быстродействию.

(4) да пусть себе по ночам тестирует и отчет шлет...

онлайн тесты всегда лажа на крупных проетах

Тестирование очень важно!

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

против тестирования ни чего не имею, но не видел реальных примеров их настоящего применения.
Всё, что мало-мальски чего-то стоит, в какой-то момент начинается с метода куяк-куяк и в продакшн, а, когда оно перерастает этот метод, оно по сути перестает развиваться.

(9) Ты мало видел. По сути все страдают от недостатка тестирования, вся ИТ-отрасль. Даже космические и военные технологии страдают, хотя там уровень покрытия кода тестами должен быть 100%, но нет, филонят.

(8) см (3)

(9) Приведу пример. Есть движок SQLiteDatabase, встроен во все смартфоны и даже 1С (журнал регистрации). Покрытие кода тестами 100%. Работает немного медленно, но стабильно и правильно всегда!

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

на (3) попробую посмотреть пристальнее. Пока смысла и - в чем профит, не вижу.

Вот SQLite реализует строго детерминированные операции над данными, команды принимает на языке SQL, имеющем строгую грамматику и математическую модель.
А прикладное решение на 1С обычно реализует безумные хотелки малограмотных манагеров или вовсе сумасшедших законодателей, входные данные принимает от сверхэнтропийной мариванны, не имеющей царя в голове.

Не в этом ли дело?

(16)Абсолютно точно не в этом. Ты как то странно сравнял требования заказчика с одной стороны и архитектуру приложения с другой. Это связанные, но разные вещи.

(1),(3) Знаем, :), спасибо. Но так это ж инструмент. Про проектирование структуры.
(4) Как? На оборот если в функции нет выборки данных, а данные приходят параметром, то гарантировано, запрос  будет один. Что часто не соблюдается.

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

Вообще в чем сложность тестирования типовых. Все компоненты очень связаны. Тестировать модульно очень трудно. Конечно есть вариант из (3), но его лучше совмещать с вариантом из (0), а для этого надо спроектировать конфигурацию так, что бы отдельные куски отвечали за получение данных, отдельные за запись, что бы их можно было изолированно тестировать.

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

(20) Это я понял, я не понял почему, любой метод
СделатьЧтоТо()

Можно разделить на
Данные = СделатьЧтоТо_ПД();
СделатьЧтоТо_ОД(Данные);

Самая поддерживаемая система тестирования xUnit1C

я пишу на ней

Ну и тестироание никак не помогает создать структуру.
А вот зарефакторить ее, очень даже

(22) В типовой или в своей?

тестирую свои доработки для ЕРП. Чтоб приобновлении не утерять

ну и плюс пару тестов на типовой вфункционал

ну и тестирование нужно только для 1 цели.
Чтоб очередной коммит не сломал то что уже работало нормально

(26) А на какие функции в своих доработках пишешь тесты?

доработка форм, заполнения всякие, печ формы

но я пишу не юнит тесты, а интеграционные

https://github.com/a-sitnikov/erp2_xtests

(32) Спасибо
(31) Вот, а речь про проектирование конфигурации для удобного модульного тестирования

MVC это кузница уродских интерфейсов.

(33) о каких интерфейсах идет речь? пользовательских, программных , аппаратных ? :)

А 100% покрытие тестами это миф. То что тест проскакивает на тестовых данных, говорит только о том что на этих данных не будет ошибок.

(35) Пользовательских, конечно.

(33) проектировать конфигурацию надо, чтобы она решала задачи и чтобы удобно было пользователям.

(37) одно другому не мешает.
Можно документ заполнять по кнопке на форме и тут же все запросы писать.
А можно функции получения данных запихать в модуль менеджера.

Кстати 1С в полсденее время стало придерживаться такого разделения. Ну кроме зупа

(36) а как оно влияет?

(36) 100% покрытие не означает, что сам код покрывает 100% ситуаций

(40) О том и речь, что функция, которая не чистая функция, а связана с данными, он  по сути, конечный автомат, если бы все функции были чистыми, то 100% покрытие кода, означало бы 100% правильность работы, ну и типы конечно в языках с динамической типизацией.

Вообще 100% покрытие экономически не выгодно.
Изменения вносить слишком сложно. слишком много тестов будет падать

(42) Наверное зависит от количества пользователей твоего продукта. Если он один то да, а если один миллион, то лучше что бы ошибок было поменьше. Тем более в той сфере в которой работает 1с

(43) https://habrahabr.ru/company/pt/blog/323294/

(22) неправда, тестер тоже хорошо поддерживается

Не знаю как у вас, а у меня обычно сроки не позволяют сделать структуру как описывает ТС.
Точнее позволяют, но этож тогда придётся работать весь день. А я так могу работать только 2-3 дня подряд.
Обычно сил хватает часов на 6-7.
Пожалуй Лефмихалыч прав.

а ТС что такое?

(47) ТопикСтартер = нулевой пост ветки

ТС хочет структуру под тестирование, но ведь инструменты разные, и такая структура не обязательна

(3) А что делать если у тебя УПП?