Наследование, говоришь, не при делах? И полиморфизм? А вот смотри, метод Подготовка(), могу поспорить, точно такой же, как и в десятке других тестов. То есть это - дублирование. А как оно устраняется? Выносится в общий родитель.

А еще десяток тестов используют другую Подготовку(). У них будет другой родитель.

Да и вообще, код

	ТестовыеДанные.ЗагрузитьИзФайла(
		"%TESTDATA%\WMS\WMS_СкладскаяОперация\" +
		"ЗафиксироватьПаллетуВДокументе_Отгрузка_тест1\*.xml",
		истина
	);


	гуид 	= "cabb49f6-6732-4d0d-96e6-2f39ebc19021";
	ссылка	= Документы.WMS_СкладскаяОперация.ПолучитьСсылку(
		новый УникальныйИдентификатор(гуид)); 

так и просится в метод родительского класса.

Пожалуйста - потребность в наследовании+полиморфизме налицо.  

Цитата:

А если у тебя несколько вариантов базовых подготовок? У тебя будет несколько общих неглобальных модулей? Или несколько процедур подготовки? И ты будет писать так?

процедура Подготовка() экспорт
	ПодготовкаТестов.ПодготовкаНомерРаз();
конецПроцедуры 

Так что ли?

В принципе, тоже вариант, но корявенький. Я же не говорю, что без наследования и полиморфизма нельзя обойтись, также как и без классов. А говорю, что с ними гораздо удобнее, код становится гораздо прозрачнее (естественно, если из применять с умом).


Цитата:

Естественно, он туда просится после обобщения. Хотя, конечно, можно и опять через общий модуль.  
Или ты хочешь сказать, что похожего кода больше ни в одном тесте нет?

sedmin
Цитата:

Подготовка тестового модуля подразумевает приведение БД к определенному известному состоянию, т.е. действия, которые там обычно выполняются - это очистка БД и загрузка рид-онли данных, на которые опираются тестовые методы данного модуля.
Вполне возможно, что упомянутые рид-онли данные используются несколькми тестовыми модулями. Но это вовсе не означает, что эти модули взаимоотносятся как "is a".

Цитата:

Нет, не будет. Считаю, что в данном случае не то дублирование, от которого нужно избавляться.

Цитата:

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

Цитата:

Похожий код есть в тестовых методах одного тестового модуля. И, естественно, в пределах этого модуля удобно выносить повторяющиеся фрагменты в приватные функции.

Вобщем, опять не убедил.

Цитата:

Сразу видно - ортодокс.
Возможности убедить - нет.   Сдаюсь. 

Цитата:

Ортодокс, приверженец... Какая разница?  

Цитата:

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

Что мне в глаза бросилось:
Цитата:
Модуля Записи регистра, например, нет, только набора
Цитата:

Однако ввода нового нет, и когда нужно заполнять новый элемент данными по-умолчанию (при открытии устанавливают в конфигурации 1с!), постоянно надо вставлять доп. проверки, что элемент введен просто, а не на основании

Цитата:
А в целом, действительно, как-то проще все получается (хотя на первом этапе модель объектная не нравилась, а справка ужасной казалась. Но это полностью пришлось самостоятельно изучать, даже книг не было). А в 7-ке все-таки часто "извращаться" приходится.

Цитата:


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

Цитата:


Это стандартное описание и для v7++ и для v8.. и даже для любого инженера, не обязательно - программиста. 

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

В v7++ такой мегапримочкой являлись классы. Очень, очень удобно проектировать, как я и писал выше. Берем тот же Sybase Power Designer, и поехали...  генерации кода, конечно, нет, как и обратного проектирования, но зато всего остального хватает с избытком. Все, что хочет пользователь, документируется, составляется словарь, рисуется матрица трассируемости требований, подбираются тесты... То есть множество работы уже сделано, и я даже еще не вошел в конфигуратор. И все благодаря тому, что есть ООП. Обрати внимание - именно на стадии проектирования оно так же важно, как и при кодировании (тестировании, сопровождении)

И только тогда, когда абсолютно понятна генеральная линия проекта, начинается, собственно, кодирование.

А что есть в восмерке (или рядом с ней) для того, чтобы облегчить нашу тяжкую жизнь? Чтобы этот цикл: проектирование - кодирование - тестирование - внедрение сделать как можно более дешевым - по времени и по деньгам?