Una de las características de firma de Go es el soporte integrado para la concurrencia.Goroutines y canales son primitivas simples y efectivas para escribir programas simultáneos. Sin embargo, la prueba de programas simultáneos puede ser difícil y propenso a errores. En Go 1.24, estamos introduciendo un nuevo paquete experimental   para apoyar la prueba de código simultáneo. Este post explicará la motivación detrás de este experimento, demostrará cómo usar el paquete synctest y discutirá su futuro potencial. testing/synctest Testado / síntesis En Go 1.24, el paquete   es experimental y no está sujeto a la promesa de compatibilidad de Go. No es visible por defecto. Para usarlo, compila tu código con   establecido en tu entorno. testing/synctest GOEXPERIMENT=synctest Testado / síntesis GOEXPERIMENT=synctest Es difícil probar programas simultáneos Para empezar, consideremos un ejemplo simple. La función   ordena que una función sea llamada en su propia goroutine después de que se cancele un contexto. context.AfterFunc context.AfterFunción Función  func TestAfterFunc(t *testing.T) { ctx, cancel := context.WithCancel(context.Background()) calledCh := make(chan struct{}) // cerrado cuando AfterFunc es llamado context.AfterFunc(ctx, func() { close(calledCh) }) // TODO: Afirme que el AfterFunc no ha sido llamado. cancel() // TODO: Afirme que el AfterFunc ha sido llamado. }  func TestAfterFunc(t *testing.T) { ctx, cancel := context.WithCancel(context.Background()) calledCh := make(chan struct{}) // cerrado cuando AfterFunc se llama context.AfterFunc(ctx, func() { close(calledCh) }) // TODO: Afirme que el AfterFunc no ha sido llamado. cancel() // TODO: Afirme que el AfterFunc ha sido llamado. }  Queremos comprobar dos condiciones en esta prueba: La función no se llama antes de que el contexto sea cancelado, y la función   llamada después de que el contexto sea cancelado. es es   es Podemos probar fácilmente que la función no ha sido llamada  , pero ¿cómo comprobamos que  ? Podemos hacer que la prueba sea menos flácida a costa de hacerla más lenta, y podemos hacerla menos lenta a costa de hacerla más flácida, pero no podemos hacerlo a la vez rápido y confiable. El paquete contiene sólo dos funciones:   y  . yet no será llamada y aún no lo hará Un enfoque común es esperar algún tiempo antes de concluir que un evento no ocurrirá. // funcCalled informa si la función fue llamada. funcCalled := func() bool { seleccionar { caso <-calledCh: devolver caso verdadero <-time.After(10 * time.Millisecond): devolver false } } si funcCalled() { t.Fatalf("AfterFunc función llamada antes de que el contexto sea cancelado") } cancel() si!funcCalled() { t.Fatalf("AfterFunc función no llamada después de que el contexto sea cancelado") }  // funcCalled informa si la función fue llamada. funcCalled := func() bool { seleccionar { caso <-calledCh: devolver caso verdadero <-time.After(10 * time.Millisecond): devolver false } } si funcCalled() { t.Fatalf("AfterFunc función llamada antes de que el contexto sea cancelado") } cancel() si!funcCalled() { t.Fatalf("AfterFunc función no llamada después de que el contexto sea cancelado") }  Esta prueba es lenta: 10 milisegundos no es mucho tiempo, pero se suma a muchas pruebas. Esta prueba también es frágil: 10 milisegundos es un largo tiempo en una computadora rápida, pero no es inusual ver pausas que duran varios segundos en sistemas compartidos y sobrecargados  . CI CI Introducción al paquete de prueba/síntesis El paquete   resuelve este problema. nos permite reescribir este test para ser simple, rápido y confiable, sin cambios en el código que se está probando. testing/synctest Testado / síntesis Run Wait Run Escucha  llama a una función en una nueva goroutina. Esta goroutina y cualquier goroutina iniciada por ella existen en un entorno aislado que llamamos una  .   espera que cada goroutina en la burbuja de la goroutina actual bloquee a otra goroutina en la burbuja. Run burbuja Wait Run bubble  Escucha Reescribamos nuestra prueba anterior usando el paquete  . testing/synctest Testado / síntesis func TestAfterFunc(t *testing.T) { synctest.Run(func() { ctx, cancel:= context.WithCancel(context.Background()) funcCalled := false context.AfterFunc(ctx, func() { funcCalled = true }) synctest.Wait() si funcCalled { t.Fatalf("AfterFunc función llamada antes de que el contexto sea cancelado") } cancel() synctest.Wait() si!funcCalled { t.Fatalf("AfterFunc función no llamada después de que el contexto sea cancelado") }) }  func TestAfterFunc(t *testing.T) { synctest.Run(func() { ctx, cancel := context.WithCancel(context.Background()) funcCalled := false context.AfterFunc(ctx, func() { funcCalled = true }) synctest.Wait() si funcCalled { t.Fatalf("AfterFunc función llamada antes de que el contexto sea cancelado") } cancel() synctest.Wait() si!funcCalled { t.Fatalf("AfterFunc función no llamada después de que el contexto sea cancelado") } } }  Esto es casi idéntico a nuestra prueba original, pero hemos envuelto la prueba en una llamada   y llamamos   antes de afirmar que la función ha sido llamada o no. synctest.Run synctest.Wait sincronización.Run síntesis. esperando La función   espera que cada goroutine en la burbuja del llamador bloquee.Cuando vuelve, sabemos que el paquete de contexto ha llamado la función, o no la llamará hasta que tomemos alguna acción adicional. Wait Escucha Esta prueba es ahora rápida y fiable. La prueba también es más simple: hemos reemplazado el canal   con un canal booleano. Anteriormente necesitábamos usar un canal para evitar una carrera de datos entre la goroutina de prueba y la goroutina  , pero la función   ahora proporciona esa sincronización. calledCh AfterFunc Wait calledCh Función  Escucha El detector de carreras entiende las llamadas  , y esta prueba pasa cuando se ejecuta con  . Si eliminamos la segunda llamada  , el detector de carreras reportará correctamente una carrera de datos en la prueba. Wait -race Wait Escucha raza Escucha  Tiempo de prueba El código competitivo a menudo trata con el tiempo. Testar el código que funciona con el tiempo puede ser difícil.Utilizar el tiempo real en las pruebas provoca pruebas lentas y flácidas, como hemos visto anteriormente.Utilizar el tiempo falso requiere evitar las funciones del paquete   y diseñar el código bajo prueba para trabajar con un reloj falso opcional. time tiempo El paquete   hace que sea más sencillo probar el código que utiliza el tiempo. testing/synctest Testado / síntesis Goroutines en la burbuja iniciada por   usan un reloj falso. Dentro de la burbuja, las funciones en el paquete   operan en el reloj falso. Run time Run tiempo Para demostrarlo, escribamos una prueba para la función  .   crea un niño de un contexto, que expira después de un determinado período de tiempo. context.WithTimeout WithTimeout context.WithTimeout Con el tiempo funcTestWithTimeout(t *testing.T) { sinctest.Run(func() { const timeout = 5 * time.Second ctx, cancel := context.WithTimeout(context.Background(), timeout) defer cancel() // Wait sólo menos que el timeout. time.Sleep(timeout - time.Nanosecond) synctest.Wait() si err : ctx.Err(); err!= nil { t.Fatalf("before timeout, ctx.Err() = %v; want nil", err) } // Wait el resto del camino hasta el timeout time.Sleeptime(Nanosecond) synctest.Wait() si err : ctx.Err(; err = ctx.Err(; err func TestWithTimeout(t *testing.T) { sinctest.Run(func() { const timeout = 5 * time.Second ctx, cancel := context.WithTimeout(context.Background(), timeout) defer cancel() // Espere sólo menos que el timeout. time.Sleep(timeout - time.Nanosecond) synctest.Wait() si err := ctx.Err(); err!= nil { t.Fatalf("before timeout, ctx.Err() = %v; quier nil", err) } // Espere el resto del camino hasta el timeout.Sleeptime(time.Nanosecond) synctest.Wait() si err := ctx.Err(); err!= context.DeadlineExceededLa única diferencia es que envuelvamos la función de prueba en  , y llamamos   después de cada llamada   para esperar a que los temporizadores del paquete de contexto terminen de funcionar. synctest.Run synctest.Wait time.Sleep sincronización.Run síntesis. esperando tiempo.Dormir Blocking y la burbuja Un concepto clave en   es que la burbuja se vuelve  . Esto ocurre cuando cada goroutina en la burbuja está bloqueada, y sólo puede ser desbloqueada por otra goroutina en la burbuja. testing/synctest permanentemente bloqueada Testado / síntesis permanentemente bloqueado Cuando una burbuja está bloqueada de forma duradera:         Si hay una llamada   saliente, se devuelve. Wait De lo contrario, el tiempo avanza a la próxima vez que podría desbloquear una goroutina, si existe. De lo contrario, la burbuja está desbloqueada y   pánico. Run Si hay una llamada  , se devuelve. Wait Escucha De lo contrario, el tiempo avanza a la próxima vez que podría desbloquear una goroutina, si existe. De lo contrario, la burbuja está bloqueada y   pánico. Run Run Una burbuja no está bloqueada de forma duradera si cualquier goroutina está bloqueada, pero puede ser despertada por algún evento desde fuera de la burbuja. La lista completa de operaciones que bloquean de forma duradera una goroutina es:               a enviar o recibir en un canal nulo a enviar o recibir bloqueado en un canal creado dentro de la misma burbuja una declaración selectiva en la que cada caso está bloqueando duraderamente time.Sleep sync.Cond.Wait sync.WaitGroup.Wait a enviar o recibir en un canal nilo un envío o recepción bloqueado en un canal creado dentro de la misma burbuja una declaración seleccionada donde cada caso está bloqueando de forma duradera tiempo.Sueño tiempo.Dormir   sync.Cond.Wait  El código sync.Cond.Wait   sync.WaitGroup.Wait sync.WaitGroup.Wait Mutaciones Las operaciones en un   no están bloqueando de forma duradera. sync.Mutex sync.Mutex Es común para las funciones adquirir un mutex global. Por ejemplo, una serie de funciones en el paquete de reflejo utilizan una caché global guardada por un mutex.Si una goroutina en una burbuja sintética bloquea mientras adquiere un mutex mantenido por una goroutina fuera de la burbuja, no está bloqueada de forma duradera: está bloqueada, pero será desbloqueada por una goroutina desde fuera de su burbuja. Dado que los mutexes generalmente no se mantienen durante largos períodos de tiempo, simplemente los excluimos de la consideración de  . testing/synctest Testado / síntesis Canales  Los canales creados dentro de una burbuja se comportan de manera diferente de los creados fuera. Las operaciones de canal sólo bloquean de forma duradera si el canal está burbujado (creado en la burbuja). Estas reglas aseguran que una goroutina se bloquee de forma duradera sólo cuando se comunica con las goroutinas dentro de su burbuja. I/O  Por ejemplo, la función   crea un par de  s que utilizan una conexión de red en memoria y pueden utilizarse en las pruebas de sincronización. Las operaciones de I/O externas, como la lectura desde una conexión de red, no están bloqueando de forma duradera. Lecturas de red pueden ser desbloqueadas por escritos procedentes de fuera de la burbuja, posiblemente incluso de otros procesos.Aunque el único escritor de una conexión de red también esté en la misma burbuja, el tiempo de ejecución no puede distinguir entre una conexión que espera que llegue más datos y una en la que el núcleo ha recibido datos y está en proceso de entregarlos. net.Pipe net.Conn net.Pipe net.Conn La vida de la burbuja La función   inicia una goroutina en una nueva burbuja. Se devuelve cuando cada goroutina en la burbuja ha salido. Se produce pánico si la burbuja está bloqueada de forma duradera y no puede desbloquearse avanzando el tiempo. Run Run El requisito de que cada goroutina en la salida de la burbuja antes de que Run regrese significa que los ensayos deben ser cuidadosos para limpiar cualquier goroutina de fondo antes de completar. Prueba del código de red Vamos a ver otro ejemplo, esta vez usando el paquete   para probar un programa en red. testing/synctest Testado / síntesis net/http Un cliente HTTP que envía una solicitud puede incluir un encabezado "Esperar: 100-continuar" para decir al servidor que el cliente tiene datos adicionales para enviar.El servidor puede entonces responder con una respuesta informativa de 100 Continuar para solicitar el resto de la solicitud, o con algún otro estado para decirle al cliente que el contenido no es necesario.Por ejemplo, un cliente que carga un archivo grande podría utilizar esta función para confirmar que el servidor está dispuesto a aceptar el archivo antes de enviarlo. Nuestra prueba confirmará que cuando se envía un encabezado "Esperar: 100 continuo", el cliente HTTP no envía el contenido de una solicitud antes de que el servidor lo solicite, y que envía el contenido después de recibir una respuesta de 100 Continuo. A menudo las pruebas de un cliente y servidor comunicante pueden usar una conexión de red loopback. Cuando trabajamos con  , sin embargo, generalmente queremos usar una conexión de red falsa para permitirnos detectar cuando todas las goroutines están bloqueadas en la red. Comenzaremos esta prueba creando un   (un cliente HTTP) que utiliza una conexión de red en memoria creada por  . testing/synctest http.Transport net.Pipe Testado / síntesis HTTP Transporte net.Pipe func Test(t *testing.T) { synctest.Run(func() { srvConn, cliConn := net.Pipe() defer srvConn.Close() defer cliConn.Close() tr := &http.Transport{ DialContext: func(ctx context.Context, red, cadena de direcciones) (net.Conn, error) {return cliConn, nil }, // Setting a non-zero timeout allows "Expect: 100-continue" handling. // Since the following test does not sleep, // we will never encounter this timeout, // even if the test takes a long time to run on a slow machine. func Test(t *testing.T) { synctest.Run(func() { srvConn, cliConn := net.Pipe() defer srvConn.Close() defer cliConn.Close() tr := &http.Transport{ DialContext: func(ctx context.Context, red, cadena de direcciones) (net.Conn, error) {return cliConn, nil }, // Setting a non-zero timeout allows "Expect: 100-continue" handling. // Since the following test does not sleep, // we will never encounter this timeout, // even if the test takes a long time to run on a slow machine. Enviamos una solicitud sobre este transporte con el conjunto de encabezados "Esperar: 100 continuo".La solicitud se envía en una nueva goroutine, ya que no se completará hasta el final de la prueba.  cuerpo := "request body" go func() { req, _ := http.NewRequest("PUT", "http://test.tld/", strings.NewReader(body)) req.Header.Set("Expect", "100-continue") resp., err := tr.RoundTrip(req) si err!= nil { t.Errorf("RoundTrip: unexpected error %v", err) } else resp {.Body.Close() }()   body := "request body" go func() { req, _ := http.NewRequest("PUT", "http://test.tld/", strings.NewReader(body)) req.Header.Set("Expect", "100-continue") resp., err := tr.RoundTrip(req) si err!= nil { t.Errorf("RoundTrip: unexpected error %v", err) } otro { resp.Body.Close() }()  Leemos los encabezados de solicitud enviados por el cliente.  req, err := http.ReadRequest(bufio.NewReader(srvConn)) si err!= nil {t.Fatalf("ReadRequest: %v", err) }   req, err := http.ReadRequest(bufio.NewReader(srvConn)) si err!= nil { t.Fatalf("ReadRequest: %v", err) }  Ahora llegamos al corazón de la prueba.Queremos afirmar que el cliente aún no enviará el cuerpo de solicitud. Empezamos una nueva goroutine copiando el cuerpo enviado al servidor en un  , esperando que todos los goroutines en la burbuja bloqueen, y comprobamos que aún no hemos leído nada del cuerpo. strings.Builder strings.Builder  Si olvidamos la llamada  , el detector de carreras se quejará correctamente de una carrera de datos, pero con el   esto es seguro. synctest.Wait Wait síntesis. esperando Escucha  var gotBody strings.Builder go io.Copy(&gotBody, req.Body) synctest.Wait() si obtuvo := gotBody.String(); obtuvo!= "" { t.Fatalf("antes de enviar 100 Continuar, inesperadamente leer cuerpo: %q", obtuvo) }   var gotBody strings.Builder ir io.Copy(&gotBody, req.Body) synctest.Wait() si obtuvo := gotBody.String(); obtuvo!= "" { t.Fatalf("antes de enviar 100 Continuar, inesperadamente leer el cuerpo: %q", obtuvo) }  Escribimos una respuesta "100 Continuar" al cliente y verificamos que ahora envía el cuerpo de solicitud.  srvConn.Write([]byte("HTTP/1.1 100 Continuar\r\n\r\n\n")) synctest.Wait() si obtuvo := gotBody.String(); obtuvo!= cuerpo { t.Fatalf("después de enviar 100 Continuar, leer cuerpo %q, quieren %q", obtuvo, cuerpo) }   srvConn.Write([]byte("HTTP/1.1 100 Continuar\r\n\r\n")) synctest.Wait() si obtuvo := gotBody.String(); obtuvo!= cuerpo { t.Fatalf("después de enviar 100 Continuar, leer cuerpo %q, quieren %q", obtuvo, cuerpo) }  Y finalmente, terminamos enviando la respuesta "200 OK" para concluir la solicitud. Hemos iniciado varias goroutines durante esta prueba. La llamada   esperará que todos salgan antes de regresar. synctest.Run sincronización.Run  srvConn.Write([]byte("HTTP/1.1 200 OK\r\n\r\n") }) }   srvConn.Write([]byte("HTTP/1.1 200 OK\r\n\r\n") }) }  Esta prueba se puede ampliar fácilmente para probar otros comportamientos, como verificar que el cuerpo de solicitud no se envía si el servidor no lo pide, o que se envía si el servidor no responde dentro de un período de tiempo. Estado del experimento Estamos introduciendo   en Go 1.24 como un paquete  . Dependiendo de los comentarios y la experiencia podemos liberarlo con o sin modificaciones, continuar el experimento, o eliminarlo en una versión futura de Go. testing/synctest experimental Testado / síntesis Experimentación  El paquete no es visible por defecto. Para usarlo, compila tu código con   establecido en tu entorno. GOEXPERIMENT=synctest GOEXPERIMENT=synctest Si intenta  , por favor informe sus experiencias, positivas o negativas, en  . «RR» testing/synctest go.dev/issue/67434 Testado / síntesis go.dev/issue/67434   Créditos: Damien Neil Créditos: Damien Neil Foto de   en  Gabriel Gusmao Unsplash Foto de   en  Gabriel Gusmao Unsplash Gabriel Gusmao Unplash     Este artículo está disponible en   bajo una licencia CC BY 4.0 DEED. The Go Blog Este artículo está disponible en   bajo una licencia CC BY 4.0 DEED. The Go Blog El blog de Go El blog de Go

Try and Download Go 

Read My Stories

Este audio es producido en el idioma original de la historia!

Aquí está cómo probar el código concurrente con la prueba / síntesis: ir 1.24

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Una breve introducción a la teoría del cerebro de Boltzmann

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Una breve introducción a la teoría del cerebro de Boltzmann

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps