2012-06-25 16 views

Respuesta

37

lo recomiendo que en vez de tratar de localizar el estilo CSS, en lugar de escribir sus pruebas para encontrar el nombre de la clase css .

De esta manera puede cambiar el estilo de css subyacente manteniendo la clase igual y sus pruebas aún pasarán.

La búsqueda del estilo subyacente es frágil. Los estilos cambian frecuentemente Basar sus rspecs en encontrar elementos de estilo específicos hace que sus pruebas sean más frágiles; es más probable que fallen cuando todo lo que hace es cambiar la apariencia de un div.

Basar sus pruebas en la búsqueda de clases de CSS hace que las pruebas sean más robustas. Les permite asegurarse de que su código esté funcionando correctamente sin tener que cambiarlos cuando cambia el estilo de la página.

En este caso específicamente, una opción puede ser definir una clase css llamada .hidden que establece display:none; en un elemento para ocultarlo.

De esta manera:

css:

.hidden { 
    display:none; 
} 

html:

<div class="hidden">HIDE ME!</div> 

capibara:

it {should have_css('div.hidden') } 

Este capibara sólo se ve un div que tiene la hidden clase: puede hacer que este emparejador sea más sofisticado si lo necesita.

Pero el punto principal es este: adjunte estilos a nombres de clase css, luego vincule sus pruebas con las clases, no con los estilos.

+11

En general, este es un buen consejo, con al menos una excepción: si está intentando probar si un elemento es visible para el usuario.Si ese es el caso, entonces probar la presencia de una clase CSS es lo incorrecto, ya que eso sería probar la implementación en lugar de los resultados, y el punto de prueba es permitirle cambiar la implementación y asegurarse de obtener el mismos resultados. Si, de hecho, está probando si un elemento es visible para el usuario, consulte la respuesta de luacassus. –

+0

@toasterlovin - usar buenas clases de CSS puede ayudar con esto, por ejemplo, es típico ver que los desarrolladores de front end avanzados usan una clase como '.is-hidden {display: none; } 'o similar que luego se agrega mediante javascript o se procesa en la carga de la página. La prueba de la existencia de esta clase sería bastante sólida; Diría que el problema radica en parte en la mala práctica ('$ (elem) .css ('display', 'none');' por ejemplo) –

+0

Estaba tratando de llegar a la diferencia entre probar la implementación (no el elemento tiene una clase que lo ocultará) y probar lo que realmente te importa (es el elemento oculto). OMI, este es un aspecto crítico para escribir pruebas útiles. Probar lo que realmente te importa significa que puedes refactorizar todo sobre cómo llegar al resultado y tu prueba te hará saber si has rediseñado correctamente. Si, por otro lado, prueba la implementación, la prueba se vuelve inútil tan pronto como cambie la implementación. –

12

Puede utilizar has_css? matcher. Puede aceptar :visible opciones. Para más detalles se puede comprobar documentos: http://rdoc.info/github/jnicklas/capybara/Capybara/Node/Matchers#has_css%3F-instance_method

Por ejemplo, usted puede intentar:

it { should have_css('div.with-some-class', :visible => true) }

+0

tenga cuidado con ': visible => true' - el resultado puede no ser exacto: [http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Element#visible%3F-instance_method] (http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Element#visible%3F-instance_method) – bershika

+0

Solo quiero señalar que el uso de la opción ': visible' puede sorprender si se usa' true 'o' falso'. He encontrado que usar 'visible:: visible' o' visible:: hidden' es más claro. [Ver detalles] (https://github.com/jnicklas/capybara/commit/83742b008f0719082beb8f6703bc70ba956815fc#diff-da1771677e47ff6a7a70b8119e14102dR58) y [discusiones sobre estas opciones de símbolos] (https://github.com/jnicklas/capybara/issues/944) – EricC

Cuestiones relacionadas