2009-07-30 8 views

Respuesta

4

Una buena relación de prueba a código es aquella que le permite sentirse confiado en el código que ha escrito y también le permite refactorizar con confianza, sabrá qué área ocupa en el resto de su aplicación. He tenido ratios de prueba que van de 1: 1.5 a 1: 2.5 o más, realmente puede variar dependiendo de la complejidad de su aplicación.

6

La relación de código a prueba es un poco estadística engañosa. Un método mucho mejor es utilizar rcov, puede utilizar fácilmente mediante la ejecución de rake spec:rcov

Mientras que la cobertura de código 100% es a veces presentado como un objetivo absoluto, se corre rápidamente en el law of diminishing returns. Personalmente aspiro a una cobertura de código del 90% en todos los códigos de producción; aunque esto es principalmente arbitrario, me resulta mucho más fácil tener un número objetivo para apuntar.

+0

Estoy de acuerdo con esto, rcov es probablemente mejor. También puede ser engañoso, si es un código realmente trivial, la cobertura puede ser menos importante, pero no siempre. Esta es un área realmente subjetiva. – nitecoder

+1

Code Coverage no es todo. rcov solo verifica si el código se ejecuta bajo prueba. No le dirá si no está probando completamente sus condicionales. –

+0

@railsninja ¿Por qué la cobertura de código es menos importante en un código trivial? ¿Porque vas a cometer menos errores en un código trivial? Creo que una mejor distinción sería si es código de producción o no. – Olly

1

Varía. Código simple. Esperaría tanto código de prueba como código de producción. El código complicado puede fácilmente merecer el doble de código de prueba. Haga un desarrollo impulsado por pruebas y no tendrá que preocuparse por la proporción, ya que todo en el código fue impulsado por una prueba y eso es lo importante.

3

Estamos hablando de opiniones en este momento. Una buena relación de código a prueba es aquella en la que su código está cubierto en la medida en que debe ser para permitir tanto la confianza en lo que está escrito como la confianza de que, cuando esté refactorizando, sabrá lo que está sucediendo a su alrededor.

Los números son buenos, pero poner demasiados valores en ellos puede ser igual de peligroso.

3

Mi objetivo no es un código no probado revelado por rcov y heckle. Cuando obtiene toda la cobertura que puede obtener con rcov, puede ejecutar el código a través de heckle. Heckle modifica tu código y te muestra qué modificaciones no fueron detectadas por las pruebas.

rspec sabe sobre heckle. Después de instalar la gema heckle: "spec foo_spec.rb -H Foo". Ah, y si obtiene un error extraño, instale la versión 1.2.2 de ruby2ruby en lugar de 1.2.4.

Aquí está heckle quejándose de una función que pensé que había determinado plenamente:

The following mutations didn't cause test failures: 

--- original 
+++ mutation 
def model_matches?(substring) 
- s = substring.gsub(/\./, ".") 
+ s = substring.gsub(/\033!\032\002l\}\?V\010d\}\r\-\fyg,a\*jFT\003_"ga\016\020ufN\0066/, ".") 
    s = substring.gsub(/\*/, ".*") 
    s = "^#{s}$" 
    Regexp.new(s, "i").=~(@model) 
end 

--- original 
+++ mutation 
def model_matches?(substring) 
- s = substring.gsub(/\./, ".") 
+ s = substring.gsub(/\./, "\023GA3w+h-#z$?I;a\"k0n^r$\005io#l\023H1M{\034m") 
    s = substring.gsub(/\*/, ".*") 
    s = "^#{s}$" 
    Regexp.new(s, "i").=~(@model) 
end 

--- original 
+++ mutation 
def model_matches?(substring) 
- s = substring.gsub(/\./, ".") 
+ s = nil 
    s = substring.gsub(/\*/, ".*") 
    s = "^#{s}$" 
    Regexp.new(s, "i").=~(@model) 
end 

--- original 
+++ mutation 
def model_matches?(substring) 
    s = substring.gsub(/\./, ".") 
    s = substring.gsub(/\*/, ".*") 
    s = "^#{s}$" 
- Regexp.new(s, "i").=~(@model) 
+ Regexp.new(s, "v\022").=~(@model) 
end 

¿No es genial?

Las únicas cosas que he encontrado que son realmente difíciles de obtener una cobertura de prueba completa son las pruebas que implican simultaneidad, esp. condiciones de carrera. Tratar de demostrar que un mutex o una sección crítica debe estar en su lugar puede ser difícil. Algunas veces puedes hacerlo. A veces, solo tienes que encogerte de hombros, poner la línea de código que no sabes cómo probar y seguir.

Cuestiones relacionadas