Как автоматизировать тестирование шаблонов Tridion (с TOM.NET) - PullRequest
10 голосов
/ 15 марта 2012

У меня повторяющаяся проблема в шаблонных проектах. Я не могу проверить свою работу иначе, чем запускать шаблоны в Template Builder. Это большая проблема, если я работаю над TBB, который используется в нескольких разных шаблонах, потому что это означает, что после изменения кода в TBB я должен повторно протестировать все шаблоны (и, возможно, с несколькими различными страницами / компонентами, как это может быть) немного разные случаи в зависимости от содержания).

Как вы можете видеть в больших проектах, где TBB многократно используются, их замена требует значительных затрат времени из-за необходимого объема тестирования, и я бы очень хотел найти решение для этого. Я знаю, что модульное тестирование практически невозможно с текущим TOM.NET (большинство классов / методов являются внутренними), так что может быть альтернативным способом достижения автоматизированного тестирования?

Одно из решений, которое я рассмотрел, состоит в том, чтобы использовать Core Service для запуска процесса рендеринга шаблона с некоторым тестовым содержимым, а затем проверить, соответствует ли вывод ожидаемым, но для достижения этого требуется довольно много кода и, таким образом, возникают нежелательные накладные расходы ( Я думаю, что это все еще занимает меньше времени, чем ручное тестирование дел). Кроме того, это на самом деле не позволяет вам тестировать отдельные TBB, если вы (программно) не создадите отдельные шаблоны с отдельными (или подмножеством) TBB. Преимущество этого решения заключается в том, что вы можете запускать тесты на локальном ноутбуке во время разработки, предполагая, что вы можете подключиться к Tridion-серверу (вам все равно придется загружать код в Tridion перед запуском тестов, поэтому это не совсем идеальное решение). ).

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

Есть еще идеи?

Ответы [ 6 ]

6 голосов
/ 16 марта 2012

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

1) Для каждого шаблона сохраняйте тестовое содержимое в отдельной папке, а тестовые страницы - в отдельной группе структур.Содержимое является исходным материалом для ваших тестов и не должно изменяться, если не изменяются требования к тестам.2) Разместите компоненты на страницах.Опубликуйте страницы.Проще говоря: у вас может быть страница для одного тестового сценария.Вы можете автоматизировать публикацию страниц, если это поможет.3) Используйте инструменты веб-тестирования, чтобы проверить вывод.Это может быть HtmlUnit, Selenium или что-то еще.

В основном - Tridion - это механизм для выполнения преобразований.Вам не нужен специализированный механизм выполнения теста для этой части, хотя его полезно использовать для тестирования выходных данных.

Насмешка над посылкой звучит привлекательно, но, как говорит Веса, это может превратиться в огромный объем работы.Простой подход, который я обрисовал в общих чертах, работает на практике, и был доказан на значительном проекте.Вы можете добавить вариации к теме, если хотите: одна вещь, которую я рассмотрел, но никогда не делала в проекте, - это использовать план для большей изоляции.Например, вы можете протестировать шаблоны страниц, локализовав шаблоны компонентов, чтобы генерировать статичные и предсказуемые представления компонентов.Достаточно сказать, что у вас будет достаточно возможностей для творчества, когда вы отцепите себя от багажа unit подходов к испытаниям.

2 голосов
/ 15 марта 2012

Я бы предложил написать свой собственный TestRunner с двумя целями: создание тестовых данных и запуск тестов.

Создание тестовых данных. Идея заключается в создании выборочного набора данных (все поля, некоторые поля и только обязательные поля автоматически). (Бонусные баллы за использование цитат Чака Норриса вместо lorem ipsum). Заголовок содержимого примера использует схему именования - например, [TestContent] и / или находится в собственной папке с прикрепленными метаданными (чтобы найти ее позже).

Создание тестовых страниц: найдите TestContent. Используйте GetListUsingItems для поиска страниц, где используется шаблон. Скопируйте страницу и вставьте ее в TestContent StructureGroup, сохраните. Откройте страницу, добавьте тестовое содержимое, удалите другое содержимое и сохраните страницу со специальной схемой именования.

Выполнение тестов: найдите TestContent, предварительно просмотрите каждый из них, запишите отчет с указанием времени рендеринга, состояния успеха и количества символов.

2 голосов
/ 15 марта 2012

У клиента я видел реализацию, в которой тесты вызывают тот же веб-сервис, который использует Template Builder, и используют их для выполнения шаблонов, оценки результатов и т. Д.

Вероятно, стоит изучить.

2 голосов
/ 15 марта 2012

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

Я полагаю, что главная проблема здесь в том, что Engine и Package запечатаны, поэтому вы не можете их легко смоделировать.Но вы можете свести к минимуму взаимодействие с этими объектами и поместить ядро ​​вашего кода в классы, которые принимают соответствующие входные данные и возвращают выходные данные, которые следует поместить в пакет и т. Д.покрытие ваших TBB только из модульных тестов с этим подходом.

2 голосов
/ 15 марта 2012

У меня есть некоторый опыт работы со сценарием CoreService. Вам просто нужно написать несколько помощников для загрузки ваших шаблонов, создания шаблонов для запуска и запуска. Однако сложная часть - это проверка.

Вам нужно будет написать несколько тестовых шаблонов, которые помогут вам с проверкой. Один из способов - написать шаблон .Net, в который вы передадите ожидаемые значения, и он выполнит проверку. Другой способ - написать шаблон DreamWeaver, который будет печатать значения из пакета, а затем вы будете сравнивать его с ожидаемым. Преимущество этого метода заключается в том, что эти значения будут возвращены вам в результате действия CoreService Render, и вы сможете выполнить всю проверку на стороне клиента.

Но самая сложная часть - это создание набора данных. Это, вероятно, займет большую часть вашего времени.

1 голос
/ 30 марта 2012

Я считаю вашу проблему полностью технологически независимой независимо от используемого вами подхода (Мышление в контексте Tridion).

Проблема в том, что вы модифицируете одну вещь, которая используется в нескольких местах (Компонент / СтраницаШаблоны) и эти места необходимо протестировать, прежде чем выдвигать это как действительное изменение.

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

Это, к сожалению, сама проблема :( Если проблема в том, что вам нужно протестировать все шаблоны, использующие этот TBB, это все еще проблема без решения. Если проблемав том, что вы не хотите влиять на текущую платформу своими изменениями / тестированием и не вмешиваться в другие события, происходящие по другому сценарию.

Я бы решил второй вариант, создав отдельную публикацию, унаследованную от публикации.с действительным кодом / данными для проверки (или что я создалn заранее), внесите свои изменения и протестируйте.Этот подход имеет смысл, если вы используете TBB как часть многих шаблонов компонентов / страниц.

Если вы обладаете роскошью гранулярности во внешнем интерфейсе (ваш tbb создает атомарный фрагмент кода), сложностьсценарий будет несколько уменьшен, но вам все равно придется протестировать все сценарии

...