Scala/Lift: Cómo escribo pruebas unitarias que prueban la respuesta de un fragmento a diferentes parámetros

Question

Estoy intentando escribir una prueba Specs2 que probará la salida de un fragmento en respuesta a diferentes parámetros que normalmente pasarían desde una plantilla , pero no he podido averiguar cómo hacerlo.

Por ejemplo, con la llamada en este fragmento div:

<div class="lift:Snippet.method?param1=foo"></div> 

Estoy pasando el param1 parámetro para el fragmento. Mi fragmento sería algo como esto:

class Snippet { 
    def method(in:NodeSeq):NodeSeq = { 
    val param1 = S.attr("param1") openOr "" 
    param1 match { 
     case "foo" => //do something 
     case "bar" => //do something else 
     case _ => //do yet another thing 
    } 
    } 
} 

Así que dentro de mi prueba, quiero probar cómo el fragmento responde a diferentes valores de param1

class SnippetTest extends Specification { 
    "Snippet" should { 
    "do something" in { 
     val html = <ul> 
      <li class="first"> 
      <li class="second"> 
      <li class="third"> 
     </ul> 

     //I need to set param1 here somehow 
     val out = Snippet.method(html) 
     //then check that it did what it was supposed to 
     out.something must be "xyz" 
    } 
    } 
} 

¿Cómo se configura param1?

Soy un gran momento scala y lift newb (viniendo de python + django), así que si estoy ladrando el árbol equivocado, por favor dirígeme a la correcta. Creo que podría ser el caso, he estado buscando en Google todo este día y no he encontrado ninguna pregunta remotamente similar a esta.

Gracias,

Blake

Answer 1

Ok, he recibido esta resuelto. Esta pregunta no ha visto mucho interés, pero en caso de que alguien esté buscando el mismo problema/pregunta, así es como lo hace:

El objeto "S" de Lift debe tener nuestros atributos arbitrarios agregados a él que le dará a nuestro fragmento los atributos que queremos probar cuando se le pregunte. Desafortunadamente, hay 2 problemas. Primero, el objeto "S" solo se inicializa cuando se recibe una solicitud http. En segundo lugar, S.attr es inmutable.

Lift tiene un paquete llamado mockweb que le permite realizar solicitudes http simuladas. La documentación de este paquete generalmente se refiere a las sesiones de prueba y los inicios de sesión de los usuarios y otras cosas, pero también proporciona mecanismos para inicializar "S" como parte de una prueba de especificación.

El primer problema, inicializando S, se resuelve definiendo nuestra clase de prueba como una extensión de WebSpec en lugar de Especificación (WebSpec es parte del paquete mockweb y amplía la Especificación) y llamando a "conSFor" durante la definición de especificación, que inicializará "S"

El segundo problema, que trata de que S.attr sea inmutable, se resuelve con el método "S" "withAttrs". "withAttrs" ejecuta un bloque de código que usted proporciona con sus atributos regulares y atributos proporcionados por usted en un mapa. Sus atributos arbitrarios solamente están disponibles de forma temporal S.attr

Aquí es la prueba de mi pregunta original que ha sido modificado para resolver los problemas: 2

import net.liftweb.mockweb._ 

class SnippetTest extends WebSpec { 
    "Snippet" should { 
    "do something" withSFor("/") in { 
     val html = <ul> 
      <li class="first"> 
      <li class="second"> 
      <li class="third"> 
     </ul> 

     //here I set param1 
     var m = new HashMap[String, String] 
     m += "param1" -> "foo" 

     val s = new Snippet() 

     //then tell S to execute this block of code 
     //with my arbitrary attributes. 
     //'out' will be the NodeSeq returned by s.method 
     val out = S.withAttrs(S.mapToAttrs(m)){ 
     s.method(html) 
     } 

     //then check that it did what it was supposed to 
     out.something must be "xyz" 
    } 
    } 
} 

edición: claridad