11.3.md

11.3casos de prueba de escritura

El proceso de desarrollo en el que un punto muy importante es poner a prueba, ¿cómo nos aseguramos la calidad del código, la forma de garantizar que cada función se ejecuta, los resultados son correctos, y cómo asegurarse de que escribir el código de rendimiento es bueno, sabemos que el enfoque del programa de prueba de unidad es encontrar un error lógico en el diseño o implementación, el problema de la exposición temprana para facilitar la colocación del problema resuelto, y las pruebas de rendimiento se centra en el diseño del programa encontró algunos problemas, por lo que el programa puede estar en línea en el caso de alta concurrencia puede mantener la estabilidad. En esta sección se llevará a esta serie de preguntas para explicar cómo el lenguaje Go para implementar las pruebas unitarias y pruebas de rendimiento.

Ir idioma viene con un marco de pruebas de peso ligero de pruebas y viene con prueba de marcha de comandos para ejecutar pruebas unitarias y pruebas de rendimiento, pruebas de marco y otro marco de pruebas de un lenguaje similar, puede estar basada en esta plataforma para crear casos de prueba para la función que corresponde también puede ser escrito basado en el marco de la prueba de presión correspondiente, a continuación, vamos a ver la forma de escribir las once.

Cómo escribir casos de prueba

Dado que la prueba vaya comando sólo se puede ejecutar en un directorio correspondiente de todos los archivos, por lo que vamos a crear un nuevo directorio del proyecto gotest , por lo que todo nuestro código y el código de prueba están en este directorio.

A continuación, creamos dos archivos en el directorio de abajo: gotest.go y gotest_test.go

1. Gotest.go: El documento que hemos creado un paquete, que tiene una función en una operación de división:

   package gotest
    
    import (
    	"errors"
    )
    
    func Division(a, b float64) (float64, error) {
    	if b == 0 {
    		return 0, errors.New("Divisor can not be 0")
    	}
    	return a / b, nil
    }

2. Gotest_test.go: Se trata de nuestros archivos de pruebas unitarias, pero hay que tener los siguientes principios:

• Los nombres de archivo deben ser _test.go final, por lo que en la ejecución de la prueba go se ejecutará cuando el código apropiado
• Usted tiene que importar el paquete testing
• Todos los casos de prueba las funciones deben ser el comienzo deTest
• Caso de prueba seguirá el código fuente escrito en la ejecución de órdenes
• la funcion de prueba TestXxx() tiene los argumentos testing.T, podemos utilizar este tipo para registrar errores o estado de la prueba
• Test format: func TestXxx(t * testing.T), Xxx sección puede ser cualquier combinación de caracteres alfanuméricos, pero no puede ser la primera letra en minúsculas [az], por ejemplo, Testintdiv mal nombre de la función.
• Funcion llamda testing.T a Error, Errorf, FailNow, Fatal, FatalIf método, la prueba no se pasa, llamando Iniciar método de prueba se utiliza para registrar la información.

Aquí está nuestro código de prueba:

package gotest

import (
	"testing"
)

func Test_Division_1(t *testing.T) {
	// try a unit test on function
	if i, e := Division(6, 2); i != 3 || e != nil { 
		// If it is not as expected, then the error
		t.Error("division function tests do not pass ") 
	} else {
		// record some of the information you expect to record
		t.Log("first test passed ") 
	}
}

func Test_Division_2(t *testing.T) {
	t.Error("just do not pass")
}

Actuamos en el directorio del proyecto de prueba go , se mostrará la siguiente información:

--- FAIL: Test_Division_2 (0.00 seconds)
gotest_test.go: 16: is not passed
FAIL
exit status 1
FAIL gotest 0.013s

A partir de este resultado muestra la prueba no pasa, ya que en la segunda función de prueba que escribimos muertos no pasan el código de prueba t.Error , entonces nuestro primer caso de cómo una función realiza la gana? Por defecto, ejecutar ir prueba no se muestra información de la prueba, tenemos que traer argumentos van test-v , esto mostrará la siguiente información:

=== RUN Test_Division_1
--- PASS: Test_Division_1 (0.00 seconds)
gotest_test.go: 11: first test passed
=== RUN Test_Division_2
--- FAIL: Test_Division_2 (0.00 seconds)
gotest_test.go: 16: is not passed
FAIL
exit status 1
FAIL gotest 0.012s

La salida muestra arriba en detalle el proceso de esta prueba, vemos que la función de prueba 1 Test_Division_1 prueba, y la función de prueba de 2 Test_Division_2 prueba falla, finalmente llegaron a la conclusión de que la prueba no se pasa. Siguiente hemos modificado la función de prueba 2 el siguiente código:

func Test_Division_2(t *testing.T) {
	// try a unit test on function
	if _, e := Division(6, 0); e == nil { 
		// If it is not as expected, then the error
		t.Error("Division did not work as expected.") 
	} else {
		// record some of the information you expect to record
		t.Log("one test passed.", e) 
	}
}

Luego ejecutamos go test-v , se muestra la siguiente información, se supera la prueba:

=== RUN Test_Division_1
--- PASS: Test_Division_1 (0.00 seconds)
gotest_test.go: 11: first test passed
=== RUN Test_Division_2
--- PASS: Test_Division_2 (0.00 seconds)
gotest_test.go: 20: one test passed. divisor can not be 0
PASS
ok gotest 0.013s

Cómo escribir la prueba de esfuerzo

Las pruebas de estrés se utiliza para detectar la función de rendimiento (método), y el método de pruebas funcionales unidad de escritura similar que no se mencionan aquí, pero es necesario prestar atención a los siguientes puntos:

• La prueba de presión debe seguir el siguiente formato, donde XXX puede ser cualquier combinación de caracteres alfanuméricos, pero no puede ser las primeras letras minúsculas letras func BenchmarkXXX (b *testing.B){...}

• Go test no tiene por defecto para realizar las pruebas de estrés de la función, si se desea realizar las pruebas de estrés deben traer argumentos -test.bench, syntax: -test.bench =" test_name_regex ", such as go test-test. bench = ". *" la totalidad de la prueba de tensión indique la función de prueba

• En la prueba de presión, por favor, recuerde utilizar el cuerpo del bucle testing.BN , por lo que la prueba puede ser el funcionamiento normal

• Nombre de archivo debe terminar con _test.go

Aquí creamos un archivo webbench_test.go prueba de esfuerzo, el código es el siguiente:

package gotest

import (
	"testing"
)

func Benchmark_Division(b *testing.B) {
	for i := 0; i < bN; i++ { // Utilice bn para recorrer
		Division(4, 5)
	}
}

func Benchmark_TimeConsumingFunction(b *testing.B) {
	b.StopTimer() // llamar a la función de detener la cuenta del tiempo de prueba de esfuerzo

	// Haga un poco de trabajo de inicialización, como los datos de archivos de lectura, las conexiones de base de datos y similares,
	// Así que probamos estos tiempos no afectan el desempeño de la función en sí

	b.StartTimer() // re- start time
	for i := 0; i < b.N; i++ {
		Division(4, 5)
	}
}

Ejecutamos el comando go test-file webbench_test.go-test.bench =". * ", Usted puede ver los siguientes resultados:

PASS
Benchmark_Division 500000000 7.76 ns/ op
Benchmark_TimeConsumingFunction 500000000 7.80 ns/ op
ok gotest 9.364s

Los resultados anteriores muestran que no se realizó ningún testXXX funciones de pruebas unitarias, los resultados muestran sólo una función de las pruebas de tensión llevadas a cabo, el primer espectáculo Benchmark_Division ejecutado 500 millones de veces el tiempo medio de ejecución es 7,76 ns, la segunda muestra la Benchmark_TimeConsumingFunction ejecutado 500 millones cada uno, el tiempo medio de ejecución es 7,80 ns. Por último, un espectáculo de tiempo total de ejecución.

Resumen

A la vista de las pruebas unitarias y pruebas de esfuerzo de aprendizaje, podemos ver la prueba de paquete es muy ligero, y las pruebas de unidad de escritura y prueba de esfuerzo es muy simple, con una función de prueba de marcha de comandos puede ser muy conveniente para la prueba, así que cada vez hemos terminado de modificar el código, haga clic en Ir. ejecución de la prueba pueden pruebas de regresión, simplemente completa.

Links

• Directory
• Previous section: Debugging by using GDB
• Next section: Summary