Testy Golanga w podkatalogu

121

Chcę utworzyć pakiet w Go z testami i przykładami dla pakietu jako podkatalogami, aby zachować czystość obszaru roboczego. Czy to możliwe, a jeśli tak, to w jaki sposób?

Cała dokumentacja zawsze umieszcza kod testowy w tym samym miejscu co inny kod, czy jest to lepsze w jakiś sposób, czy po prostu w konwencji?

build go

— Pełen wdzięku pingwin
źródło

5

Uwaga: go test ./...uruchomi testy na bieżącym folderze i wszystkich podfolderach. Zobacz moją odpowiedź poniżej

— VonC,

Możliwy duplikat „ Jak przejść test” wszystkich testów w moim projekcie?

— Matthew Rankin

myślałem to samo. mam problem z testowaniem oddzielnego katalogu, ponieważ reżyser na tym samym poziomie ma sub-reż.

— filthy_wizard

203

Zauważ, że możesz uruchamiać go test"rekurencyjnie": musisz wypisać wszystkie pakiety, które chcesz przetestować .

Jeśli jesteś w folderze głównym projektu Go, wpisz:

go test ./...

./...Notację „ ” opisano w sekcji „ Opis list pakietów ” poleceniago „ polecenie ”:

Ścieżka importu jest wzorcem, jeśli zawiera jeden lub więcej ...symboli wieloznacznych, z których każdy może pasować do dowolnego ciągu, łącznie z pustym ciągiem i ciągami zawierającymi ukośniki.

Taki wzorzec rozszerza się na wszystkie katalogi pakietów znalezione w GOPATHdrzewach o nazwach pasujących do wzorców.

W specjalnym przypadku x/...dopasowania, xa także xpodkatalogi użytkownika.
Na przykład, net/...rozwija się do neti pakuje w swoich podkatalogach.

Jeśli przechowujesz _test.gopliki w podfolderze, polecenie „ go test ./...” będzie mogło je pobrać.
Ale:

będziesz musiał poprzedzić wyeksportowane zmienne i funkcje (używane w testach) nazwą pakietu, aby plik testowy miał dostęp do wyeksportowanej zawartości pakietu.
nie masz dostępu do niewyeksportowanych treści.

Biorąc to pod uwagę, nadal wolałbym trzymać _test.goplik tuż obok głównego pliku źródłowego: łatwiej go znaleźć.

— VonC
źródło

4

Niektórzy mogą twierdzić, że brak dostępu do prywatnych rzeczy jest normalnym testowaniem czarnoskrzynkowym i lepszym. Jeśli chodzi o konieczność zakwalifikowania symboli publicznych, zawsze możesz zaimportować _ "...".

— ddevienne

15

Umieść testy wraz z kodem w tym samym katalogu w pliku o nazwie, file_test.gogdzie „plik” to nazwa testowanego pliku kodu źródłowego. To jest konwencja i z własnego doświadczenia stwierdziłem, że jest najlepsza.

Jeśli go testnarzędzie nie jest wystarczająco zautomatyzowane, możesz zajrzeć do GoConvey , który ma interfejs sieciowy, który automatycznie aktualizuje i uruchamia tradycyjne testy Go, a także testy GoConvey (które są oparte na zachowaniu i są bardziej samodokumentujące niż tradycyjne testy Go).

— Matt
źródło

2

GoConvey jest niesamowity (iz niecierpliwością czekam na nowy interfejs użytkownika). Używam go w moim obecnym projekcie , na przykład na github.com/VonC/asciidocgo/blob/master/abstractNode_test.go ). Jednak go testmoże również działać dla podfolderów. Zobacz moją odpowiedź poniżej

— VonC,

Masz rację. W rzeczywistości jest to prawdopodobnie bardziej istotne niż moja odpowiedź na to pytanie.

— Matt,

10

EDYTOWANE

Zbudowany na odpowiedzi VonC,

Ta odpowiedź jest ważna w go1.11. Nie testowano jeszcze w wyższych gowersjach.

Dla tych z Was, którzy lubią trzymać swoje testy w podfolderze, powiedzmy test, a potem uruchomione

go test ./...

spróbuje uruchomić testy w każdym folderze, nawet w tych, które nie zawierają żadnego testu, mając tym samym ?w kolejnym raporcie dla folderów innych niż testowe.

Bieganie

go test ./.../test

zamiast tego będzie kierować tylko na twoje testfoldery, dzięki czemu czysty raport będzie koncentrował się tylko na folderach testów.

UWAGA

Należy pamiętać, że korzystanie z podfolderów testowych uniemożliwi obliczenie raportu pokrycia. Filozofia go polega na pozostawieniu plików testowych w folderach pakietów.

— avi.elkharrat
źródło

1

Dobra wskazówka, oprócz mojej odpowiedzi sprzed pięciu lat. Głosowane za

— VonC

droga anno, proszę wyjaśnij, co nie działa? a jaka jest Twoja wersja go? co próbujesz zrobić? Później zdałem sobie sprawę, że ta metoda nie pozwala na obliczenie pokrycia kodu, a szkoda. Czy to masz na myśli?

— avi.elkharrat

1

go test ./.../testzwraca go: warning: "./.../test" matched no packages// nie tylko kieruje na foldery testowe. wersja go go1.13 darwin / amd64

— anna

1

@Madeo, miałoby to sens, ponieważ golang nie zachęca do segregacji testów i kodu. Anomalia polegała na umożliwieniu tego w poprzednich wersjach.

— avi.elkharrat

1

@ avi.elkharrat i faktycznie zdecydowałem się nie stosować tego podejścia, mimo że lubiłem trzymać testy w osobnym pakiecie / folderze = (

— Madeo

-4

Zwykle nie testuję, ale możesz pogrupować plik w katalogi i użyć funkcji importu

import "./models"jeśli jest jeden poziom na zewnątrz,
import "../modelsjeśli jest jeden poziom na zewnątrz i jeden poziom na zewnątrz

Na przykład dla:
./models/todo.go
./test/todo_test.go

do testu todo.goz todo_test.go, importowanie w todo_test.gobędzie

import "../models"

— Felix Zilla
źródło

Ta metoda importowania kodu działa tylko w przypadku ujawnionych funkcji. Wygląda na to, że nie zachowuje się tak, jakby znajdowały się w tym samym pakiecie, nawet jeśli wyraźnie umieściłeś je w tym samym pakiecie. Więc to rozwiązanie tak naprawdę nie rozwiązuje problemu testów jednostkowych.

— The Graceful Penguin