Cómo automatizar las pruebas de las plantillas de Tridion (con TOM.NET)

Question

Tengo un problema recurrente en la creación de plantillas de proyectos. Realmente no puedo probar mi trabajo de otra manera que ejecutar las plantillas en el Creador de plantillas. Este es un problema importante si estoy trabajando en un TBB que se usa en varias plantillas diferentes porque significa que después de cambiar el código en el TBB debería volver a probar todas las plantillas (y probablemente con varias páginas/componentes diferentes ya que podría haber casos ligeramente diferentes según el contenido).

Como puede ver en los grandes proyectos donde los TBB se reutilizan mucho, cambiarlos cuesta mucho tiempo debido a la cantidad de pruebas necesarias y estaría ansioso por encontrar una solución para esto. Sé que la prueba unitaria es prácticamente imposible con el TOM.NET actual (la mayoría de las clases/métodos son internos) entonces, ¿qué podría ser una alternativa forma de lograr prueba automatizada?

Una solución que he analizado es utilizar Core Service para iniciar el proceso de renderización de una plantilla con contenido de prueba y luego verificar si el resultado es el esperado, pero lograr esto requiere bastante código y produce una sobrecarga indeseada (Creo que aún toma menos tiempo que volver a probar manualmente los casos). Además, esto realmente no le permite probar TBB individuales a menos que (programáticamente) cree plantillas separadas con TBB individuales (o un subconjunto). Lo bueno de esta solución es que podría ejecutar las pruebas en su computadora portátil local mientras se desarrolla, suponiendo que pueda conectarse a Tridion-server (aún tendría que cargar su código a Tridion antes de ejecutar las pruebas, por lo que su solución no es completamente ideal)

Sé que otra alternativa es usar DD4T/CWA donde puede manejar prácticamente todas las pruebas en el front-end ya que las plantillas son (por lo general) bastante simples.

¿Alguna otra idea?

Answer 1

I de acuerdo en que el énfasis está en automatizados pruebas en lugar de unidad pruebas (que, después de todo, es sobre todo acerca de la programación orientada a objetos). Con Tridion funciona, se trata de transformar datos. Lo que necesita para probar las transformaciones de datos es tener entradas conocidas y poder hacer afirmaciones sobre las salidas. He intentado varios enfoques a lo largo de los años, pero el más eficaz hasta ahora ha sido el siguiente:

1) Para cada plantilla, mantenga el contenido de prueba en una carpeta dedicada y páginas de prueba en un grupo de estructura dedicado. El contenido es la entrada para sus pruebas, y no tiene la intención de cambiar a menos que cambien los requisitos de la prueba. 2) Coloque los componentes en las páginas. Publica las páginas. Mantenlo simple: a menudo puedes tener una página para un escenario de prueba único. Puede automatizar la publicación de las páginas si eso ayuda. 3) Use herramientas de prueba web para verificar el resultado. Esto podría ser HtmlUnit, Selenium o lo que sea.

Básicamente, Tridion es un motor para ejecutar transformadas. No necesita un motor de ejecución de prueba especializado para esta parte, aunque es útil usar uno para probar la salida.

Burlarse del paquete suena atractivo, pero como dice Vesa, puede convertirse en una gran cantidad de trabajo. El enfoque simple que he delineado funciona en la práctica, y fue probado en un proyecto significativo. Podría agregar variaciones sobre el tema si lo desea: una cosa que he considerado, pero que nunca hice en un proyecto, es usar el modelo para darle más aislamiento. Por ejemplo, puede probar sus plantillas de página localizando las plantillas de sus componentes para generar presentaciones de componentes estáticos y predecibles. Baste decir que hay suficiente margen para la creatividad una vez que se libera del equipaje de unidad enfoques de prueba.

Answer 2

Tengo un poco de experiencia con el escenario CoreService. Solo tendrá que escribir algunos ayudantes para cargar sus plantillas, crear plantillas de cupound y ejecutarlo. La parte difícil, sin embargo, es la verificación.

Tendrá que escribir algunas plantillas de prueba que lo ayudarán con la verificación. Una forma es escribir la plantilla .Net a la que pasará los valores esperados y hará la verificación. La otra forma es escribir la plantilla DreamWeaver que imprimirá los valores del paquete y luego la comparará con lo esperado. La ventaja de este método es que estos valores le serán devueltos como resultado de la acción Render de CoreService y puede hacer toda la verificación en el lado del cliente.

Pero la parte más difícil es la creación del conjunto de datos. Probablemente te tome la mayor parte de tu tiempo.

Answer 3

Puede tratar de aislar la mayoría del código en las clases que se pueden probar unitarias.

Supongo que el principal problema aquí es que el motor y el paquete están sellados, por lo que no es fácil burlarse de ellos. Pero puede minimizar la interacción con esos objetos y poner la carne de su código en las clases que toman la entrada correspondiente y devolver la salida que debe colocarse en el paquete, etc.

Creo que podría obtener mucha cobertura de sus TBB solo a partir de pruebas unitarias con este enfoque.

Answer 4

En un cliente que he visto una aplicación donde las pruebas están invocando el mismo servicio web que utiliza Template Builder, y que utilizan para ejecutar las plantillas, evaluar los resultados, etc.

Probablemente vale la pena explorar.

Answer 5

Sugeriría escribir su propio TestRunner con 2 objetivos: crear datos de prueba y ejecutar pruebas.

Crear datos de prueba: la idea es crear un conjunto de datos de muestra (todos los campos, algunos campos y solo campos obligatorios automáticamente). (Puntos de bonificación por usar citas de Chuck Norris en lugar de lorem ipsum). El título del contenido de muestra utiliza un esquema de nombres, como [TestContent] y/o está en su propia carpeta con los metadatos adjuntos (para encontrarlo más adelante).

Crear páginas de prueba: Encuentre TestContent. Use GetListUsingItems para buscar páginas donde se usa la plantilla. Copie la página y péguela en un TestContent StructureGroup, guarde. Abra la página, agregue el contenido de prueba, elimine el otro contenido y guarde la página con un esquema de nombres especial.

Ejecutar pruebas: encuentre TestContent, obtenga una vista previa de cada una, escriba el informe con el tiempo de renderizado, el estado de éxito y el # de caracteres.

Answer 6

Considero que su problema es totalmente independiente de la tecnología independientemente del enfoque que utilice (Pensando en el contexto de Tridion).

El problema es que está modificando una cosa que se usa en varios lugares (Componente/Plantillas de página) y esos lugares deben probarse antes de presionar como un cambio válido.

Incluso si realiza los cambios adecuados, suponga que el código funciona bien y tiene un resultado, quizás no sea el resultado esperado por otros TBB que consumen su salida .

Desafortunadamente, este es el problema :( Si el problema es que tiene que probar todas las plantillas con ese TBB, sigue siendo un problema sin solución. Si el problema es que no desea afectar la plataforma actual con sus cambios/pruebas ni interferir con otros desarrollos que van en , es un escenario diferente.

Resolvería el segundo creando una publicación separada heredando de la publicación con código/datos válidos para probar (o haber creado eso por adelantado), realizar los cambios allí y probar. Este enfoque tiene sentido si está utilizando el TBB como parte de muchas Plantillas de Componente/Página.

Si usted tiene el lujo de la granularidad en el extremo delantero (el TBB produce una pieza atómica de código) la complejidad del escenario sería ligeramente reducido, pero todavía tiene que probar todos los escenarios de todos modos