Golang prova nella sottodirectory

121

Voglio creare un pacchetto in Go con test ed esempi per il pacchetto come sottodirectory per mantenere lo spazio di lavoro più pulito. È possibile e se sì come?

Tutta la documentazione mette sempre il codice di test nello stesso posto dell'altro codice, è meglio in qualche modo o solo per convenzione?

build go

— Il grazioso pinguino
fonte

5

Nota: go test ./...eseguirà i test sulla cartella corrente e su tutte le sottocartelle. Vedi la mia risposta di seguito

— VonC

Possibile duplicato di Come `andare a testare` tutti i test nel mio progetto?

— Matthew Rankin

Stavo pensando la stessa cosa. avere problemi a mettere i test in una directory separata perché i direttori sullo stesso livello hanno sottodirectory.

— filthy_wizard

203

Nota che puoi eseguire go test"ricorsivamente": devi elencare tutti i pacchetti che vuoi testare .

Se ti trovi nella cartella principale del tuo progetto Go, digita:

go test ./...

La ./...notazione " " è descritta nella sezione " Descrizione degli elenchi di pacchetti " del " comandogo ":

Un percorso di importazione è un modello se " ..." include uno o più caratteri jolly, ciascuno dei quali può corrispondere a qualsiasi stringa, inclusa la stringa vuota e le stringhe contenenti barre.

Un tale modello si espande a tutte le directory dei pacchetti trovate negli GOPATHalberi con nomi che corrispondono ai modelli.

In un caso speciale, x/...corrisponde xanche xalle sottodirectory di.
Ad esempio, si net/...espande in nete confezioni nelle sue sottodirectory.

Se mantieni i tuoi _test.gofile in una sottocartella, il go test ./...comando " " sarà in grado di raccoglierli.
Ma:

sarà necessario anteporre alle variabili e alle funzioni esportate (utilizzate nei test) il nome del pacchetto, affinché il file di test possa accedere al contenuto esportato del pacchetto.
non accederai a contenuti non esportati.

Detto questo, preferirei comunque mantenere il _test.gofile accanto al file sorgente principale: è più facile da trovare.

— VonC
fonte

4

Alcuni potrebbero obiettare che il mancato accesso a cose private è un normale test da scatola nera e migliore. Per quanto riguarda la qualificazione dei simboli pubblici, puoi sempre importare _ "...".

— ddevienne

15

Metti i tuoi test insieme al tuo codice nella stessa directory in un file chiamato file_test.godove "file" è il nome del file del codice sorgente che stai testando. Questa è una convenzione e l'ho trovata la migliore nella mia esperienza.

Se lo go teststrumento non è abbastanza automatizzato per te, potresti esaminare GoConvey , che ha un'interfaccia utente web che aggiornerà automaticamente ed eseguirà i test Go tradizionali e i test GoConvey (che si basano sul comportamento e sono più auto-documentanti rispetto ai tradizionali Go test).

— opaco
fonte

2

GoConvey è fantastico (e sto aspettando la nuova interfaccia utente con grande attesa). Lo sto usando nel mio progetto attuale come in github.com/VonC/asciidocgo/blob/master/abstractNode_test.go , per esempio). Tuttavia, go testpuò funzionare anche per le sottocartelle. Vedi la mia risposta di seguito

— VonC

Hai ragione. In effetti, è probabilmente più pertinente della mia risposta a questa domanda.

— Matt

10

MODIFICATO

Basato sulla risposta di VonC,

Questa risposta è valida in go1.11. Non ancora testato nelle goversioni superiori .

Per quelli di voi a cui piace tenere i test in una sottocartella, diciamo test, quindi in esecuzione

go test ./...

tenterà di eseguire i test in ogni cartella, anche quelli che non contengono alcun test, avendo così ?nel report successivo per cartelle non test.

In esecuzione

go test ./.../test

invece mirerà solo alle tue testcartelle, avendo così un rapporto pulito focalizzato solo sulle cartelle dei tuoi test.

ATTENZIONE

Tenere presente che l'utilizzo di sottocartelle di test impedirà il calcolo del report di copertura. La filosofia di go è lasciare i file di test nelle cartelle dei pacchetti.

— avi.elkharrat
fonte

1

Buon consiglio, in aggiunta alla mia risposta di cinque anni. Votato

— VonC

cara anna, per favore spiegami cosa non funziona? e qual è la tua versione di go? Cosa stai cercando di fare? In seguito mi sono reso conto che questo metodo non consente di calcolare la copertura del codice, il che è un peccato. È ciò che intendi?

— avi.elkharrat

1

go test ./.../testrestituisce go: warning: "./.../test" matched no packages// non si rivolge solo alle cartelle di test. vai versione go1.13 darwin / amd64

— anna

1

@Madeo, questo avrebbe senso, perché Golang non incoraggia la segregazione di test e codice. L'anomalia era di consentirlo nelle versioni precedenti.

— avi.elkharrat

1

@ avi.elkharrat e infatti ho deciso di non ricorrere più a questo approccio, anche se mi piaceva tenere i miei test in un pacchetto / cartella separato = (

— Madeo

-4

Normalmente non eseguo test, ma puoi raggruppare il tuo file in directory e usare import like

import "./models"se è un livello fuori
import "../modelsse è un livello fuori e un livello dentro

Ad esempio, per:
./models/todo.go
./test/todo_test.go

per testare todo.godal todo_test.go, l'importazione nella todo_test.gosarà

import "../models"

— Felix Zilla
fonte

Questo metodo di importazione del codice funziona solo per le funzioni esposte. Non sembra comportarsi come se fossero nello stesso pacchetto, anche se li hai messi esplicitamente nello stesso pacchetto. Quindi questa soluzione non risolve realmente il problema per i test unitari.

— The Graceful Penguin