Подтвердить что ты не робот

Как автоматизировать тестирование шаблонов Tridion (с помощью TOM.NET)

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

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

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

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

Любые другие идеи?

4b9b3361

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Я думаю, вы могли бы получить большое освещение своих TBB только от модульных тестов с помощью этого подхода.

Ответ 4

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

Возможно, стоит изучить.

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

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