![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2020\/09\/22144542\/TestifyBlog-03.png\")
<\/p>\n<\/p>\n
UPDATE: Am 1. Mai 2021 wird das zentrale Repository von GoCenter einschlie\u00dflich aller Funktionen eingestellt. Weitere Informationen zur Einstellung der Center finden Sie im Blog-Beitrag zur Einstellung<\/a><\/span><\/p>\n <\/p>\n <\/p>\n Jeden Monat verleiht GoCenter den leistungsst\u00e4rksten Modulen ein <\/b>Gopher Badge<\/b><\/a> als Auszeichnung f\u00fcr ihre Leistung. Wir schreiben \u00fcber einige dieser <\/b>Top-Module<\/b><\/a> und wie sie in Go verwendet werden.<\/b><\/span><\/p>\n Jeder Entwickler hat sie schon gesehen, selbst in gut strukturierten Golang-Programmen: Kommentare, die vorschlagen, dass man sich von Codezeilen fernhalten sollte, da diese auf magische Weise zu funktionieren scheinen. Diese Warnungen machen uns \u00e4ngstlich, weil wir glauben, wir k\u00f6nnten etwas kaputt machen. Aber Anwendungen m\u00fcssen sich \u00e4ndern, um besser zu werden und innovativ zu sein.<\/span><\/p>\n Deshalb sind Unit-Tests ein wichtiger Bestandteil der Softwareentwicklung. Sie helfen den Entwicklern zu wissen, ob die kleinen Teile ihrer Software ihre vorgesehene Funktion korrekt erf\u00fcllen. Mit dem richtigen Umfang an Unit-Tests f\u00fchlen sich Entwickler sicherer, ihre Implementierungen zu \u00e4ndern und sogar von Grund auf neu zu refaktorisieren. Sie wissen dann n\u00e4mlich, dass sie leicht \u00fcberpr\u00fcfen k\u00f6nnen, ob die neue Version immer noch wie vorgesehen funktioniert.<\/span><\/p>\n Je komplexer die Software wird, desto wichtiger werden Unit-Tests, ebenso wie ein solider Satz von daf\u00fcr vorgesehenen Tools in der gleichen Sprache. Und da Testcode mit guter Abdeckung sehr umfangreich sein kann, muss er genauso lesbar und wartbar sein wie der Produktcode, damit Entwickler ihn verwenden und seine Vorteile nutzen.<\/span><\/p>\n F\u00fcr unsere Go-Community-Projekte wie GoCenter nutzen wir ausgiebig das beliebte <\/span>Testify<\/span>-Modul, das eine Reihe von Golang-Paketen f\u00fcr die Durchf\u00fchrung wichtiger Unit-Test-Funktionen bereitstellt.<\/span><\/p>\n In diesem Artikel erfahren Sie, wie Sie die wichtigsten Funktionen von Testify nutzen k\u00f6nnen, um Unit-Tests in Go zu schreiben, die einfach zu lesen und zu warten sind. Der Artikel beschreibt, wie Unit-Tests bei der Verwendung von reinem Go aussehen w\u00fcrden, wobei die Pakete von Testify vorgestellt werden, die bei der zu erledigenden Aufgabe helfen k\u00f6nnen. Anschlie\u00dfend sehen Sie den Code, der sich nach der Anwendung von Testify ergibt. Wir zeigen einige Best Practices, wie man Assertions durchf\u00fchrt und Mocks f\u00fcr Abh\u00e4ngigkeiten schreibt.<\/span><\/p>\n Testify<\/b> ist ein entwicklerfreundlicher Satz von Paketen mit \u00fcber 11.000 Sternen auf GitHub und gro\u00dfer Unterst\u00fctzung durch die Community. Testify erweitert das schlanke Diese Funktionen sowie das t\u00e4gliche Vertrauen unseres Go-Community-Teams darauf sind ein gro\u00dfer Teil der Gr\u00fcnde, warum das Testify-Modul als <\/span>"Top-Gopher" im GoCenter ausgezeichnet wurde<\/span><\/a>. Wenn Sie sich die umfangreichen Metadaten von GoCenter f\u00fcr das Testify-Modul ansehen, <\/span>wissen Sie, warum:<\/p>\n<\/div>\n Um mit dem Schreiben der Unit-Tests zu beginnen, ben\u00f6tigen wir zun\u00e4chst eine zu pr\u00fcfende Komponente. F\u00fcr diese \u00dcbung werden wir die folgende Dienstdefinition verwenden:<\/span><\/p>\n <\/p>\n F\u00fcr diese Dienstdefinition haben wir eine Implementierung und wir wollen diese zu testen. Die Implementierung verf\u00fcgt \u00fcber einige Business-Logik, um zu bestimmen, ob ein Produkt reservierbar ist oder nicht. Die Implementierung h\u00e4ngt auch von einer Data Access Object-Komponente ab, um Informationen \u00fcber die Produkte bereitzustellen. Die Implementierung muss die folgenden vereinfachten Testf\u00e4lle bestehen:<\/span><\/p>\n Die Dienstimplementierung sieht wie folgt aus:<\/span><\/p>\n Da wir nun einen einfachen Dienst haben, k\u00f6nnen wir mit Testify Unit-Tests erstellen, die gew\u00e4hrleisten, dass er wie vorgesehen funktioniert.<\/span><\/p>\n Die grundlegendsten Aufgaben, die von Unit-Tests ausgef\u00fchrt werden, sind Assertions. Assertions werden in der Regel verwendet, um zu \u00fcberpr\u00fcfen, ob die vom Test durchgef\u00fchrten Aktionen unter Verwendung bestimmter Eingaben das erwartete Ergebnis erzeugen. Sie k\u00f6nnen auch verwendet werden, um zu pr\u00fcfen, ob die Komponenten den gew\u00fcnschten Designregeln entsprechen. <\/span><\/p>\n Wenn wir mit reinem Go die Assertions ausf\u00fchren, die ben\u00f6tigt werden, um zu pr\u00fcfen, ob der erste Testfall anerkannt und unsere Dienstimplementierung richtig initialisiert wird, erhalten wir den folgenden Code:<\/span><\/p>\n Als Hilfe f\u00fcr die Assertions enth\u00e4lt Testify das Paket <\/span> Neben der Hilfe bei den Assertions bieten die Testify-Pakete auch eine bessere Benachrichtigung, wenn eine dieser Operationen fehlschl\u00e4gt. Wenn wir zum Beispiel vergessen haben, das productDAO-Feld im Konstruktor der Dienstimplementierung zu setzen, w\u00fcrden wir den folgenden Testfehler erhalten:<\/span><\/p>\n Bisher konnten wir trotz besserem Messaging und bequemerer Methoden zur Ausf\u00fchrung der Assertions den Umfang unseres Tests nicht reduzieren. Wir haben immer noch ein sich wiederholendes Muster von "if-not-assertion-break", das es schwieriger machen kann, unseren Testcode zu lesen. Um dabei zu helfen, enth\u00e4lt Testify das Paket <\/span> <\/p>\n Wenn wir eine Komponente testen, wollen wir sie im Idealfall vollst\u00e4ndig isolieren, um zu vermeiden, dass Fehler an anderer Stelle unsere Tests beeintr\u00e4chtigen. Dies ist besonders schwierig, wenn die Komponente, die wir testen wollen, Abh\u00e4ngigkeiten zu anderen Komponenten aus verschiedenen Schichten unserer Software hat. In dem hier verwendeten Szenario h\u00e4ngt unsere Dienstimplementierung von einer Komponente aus der Data Access Object (DAO)-Schicht ab, um auf Informationen \u00fcber die Produkte zuzugreifen.<\/span><\/p>\n Um die gew\u00fcnschte Isolation zu f\u00f6rdern, ist es \u00fcblich, dass Entwickler unechte, vereinfachte Implementierungen dieser Abh\u00e4ngigkeiten schreiben, die w\u00e4hrend der Tests verwendet werden. Diese unechten Implementierungen werden Mocks genannt.<\/span><\/p>\n Wir k\u00f6nnen eine Mock-Implementierung des ProductDAO erstellen, die in die Dienstimplementierung f\u00fcr die Testausf\u00fchrung injiziert wird. Die ProductDAO-Schnittstelle, die unser Mock implementieren muss, sieht wie folgt aus:<\/span><\/p>\n Um die Testausf\u00fchrung zu erm\u00f6glichen, ist es notwendig, dass der Mock ein Verhalten zeigt, das mit allen Testf\u00e4llen, die wir validieren wollen, kompatibel ist, da wir sonst nicht die gew\u00fcnschte Testabdeckung erreichen k\u00f6nnen. Mit reinem Go w\u00fcrde unser Testfall mit dem Mock wie folgt aussehen:<\/span><\/p>\n <\/p>\n Das Hauptproblem mit dem obigen Ansatz ist, dass unsere Testfalllogik nun verteilt ist. Ein Teil davon ist im Testfall selbst implementiert, wo wir Ereignisse an die getestete Komponente senden und Assertions mit den Ergebnissen ausf\u00fchren, w\u00e4hrend der andere Teil im Mock implementiert ist. Dieser wiederum muss ein Verhalten bereitstellen, das mit dem des Testfalls kompatibel ist. Es ist leicht zu erkennen, wie unser Testfall jetzt abgebrochen werden k\u00f6nnte, und zwar nicht wegen eines Problems im Test selbst, sondern weil der Mock nicht die erforderlichen Daten zur\u00fcckgibt. <\/span><\/p>\n Ein weiteres Problem, das die Sache noch frustrierender machen kann, ist die Tatsache, dass wir den Mock auf mehrere Testf\u00e4lle verteilen. Es ist m\u00f6glich, dass \u00c4nderungen, die am Mock vorgenommen werden, um die Erfordernisse eines Testfalls zu erf\u00fcllen, andere Testf\u00e4lle zerst\u00f6ren. In unserem Szenario haben wir nur 3 Testf\u00e4lle, um die wir uns k\u00fcmmern. Sie k\u00f6nnen sich aber vorstellen, wie un\u00fcbersichtlich es werden k\u00f6nnte, wenn wir komplexere Testf\u00e4lle h\u00e4tten. Eine Aufteilung des Mocks in mehrere w\u00fcrde nicht unbedingt helfen, sondern k\u00f6nnte die Komplexit\u00e4t sogar noch erh\u00f6hen. Wenn sich unsere gemockte Schnittstelle \u00e4ndert, m\u00fcssten wir au\u00dferdem mehrere Mocks aktualisieren, um sie kompatibel zu halten.<\/span><\/p>\n Was wir brauchen, ist, dass die Testfalllogik zentralisiert und unabh\u00e4ngig bleibt. Um dabei zu helfen, enth\u00e4lt Testify das Paket <\/span> Durch die Verwendung des Testify-Mock-Pakets zur Erstellung unseres DAO-Mocks und das Verschieben der Initialisierung des Mock-Verhaltens in die Testf\u00e4lle sowie das Hinzuf\u00fcgen des Testify-Require-Pakets zur Ausf\u00fchrung unserer Assertions sieht unser Testcode wie folgt aus:<\/span><\/p>\n In der obigen Implementierung sehen Sie, wie das Mock-Verhalten und die Testlogik innerhalb des Testfalls zentralisiert sind. Beachten Sie auch, dass das erfasste Scheinverhalten ausschlie\u00dflich f\u00fcr den Testfall gilt, in dem es platziert ist, da es zu einer einzelnen Mock-Instanz geh\u00f6rt, die nicht von mehreren Tests gemeinsam genutzt wird. Die Tests erfassen ohne jegliche Probleme sogar unterschiedliche Verhaltensweisen f\u00fcr die Produkt-ID 1. ProductDaoTestifyMock kann sicher zwischen mehreren Testf\u00e4llen wiederverwendet werden, da es kein Verhalten hat.<\/span><\/p>\n Ich hoffe, Sie haben n\u00fctzliche Informationen in diesem Artikel gefunden und ich hoffe, dass er Ihnen helfen kann, bessere Unit-Tests in Ihren Projekten zu schreiben. Um Testify mit Go-Modulen zu Ihrem Projekt hinzuzuf\u00fcgen und damit zu spielen, f\u00fchren Sie einfach die folgenden Befehle aus:<\/span><\/p>\n Sehen Sie sich Testify auf GoCenter an<\/span> oder suchen Sie, um noch mehr tolle Go-Module zu entdecken.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" UPDATE: Am 1. Mai 2021 wird das zentrale Repository von GoCenter einschlie\u00dflich aller Funktionen eingestellt. Weitere Informationen zur Einstellung der Center finden Sie im Blog-Beitrag zur Einstellung Jeden Monat verleiht GoCenter den leistungsst\u00e4rksten Modulen ein Gopher Badge als Auszeichnung f\u00fcr ihre Leistung. Wir schreiben \u00fcber einige dieser Top-Module und wie sie in Go …<\/p>\n","protected":false},"author":140,"featured_media":64448,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[9969,9436],"tags":[9439,9437,9438],"class_list":["post-80770","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artefakt-management","category-go-de","tag-go-de","tag-go-module","tag-gocenter-de"],"yoast_head":"\nTestify: Ein Top-Gopher<\/span><\/h2>\n
Test<\/code> -Framework von Go, um Assertions und Mock-Abh\u00e4ngigkeiten durchzuf\u00fchren.<\/span><\/p>\n\n\n\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2020\/09\/03205610\/Go-Badge.png\"){kind=icon}
<\/div>\n<\/div>\n<\/div>\n\n
\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2020\/09\/22144634\/Testify-Metrics-1024x457.png\")
<\/li>\n
\n![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2020\/09\/22144725\/Testify-Security-1024x210.png\")
\n<\/span><\/li>\n<\/ul>\nEine einfache GoLang-Unit<\/span><\/h2>\n
\ntype ProductService interface {\r\n\tIsProductReservable(id int) (bool, error)\r\n}<\/span><\/pre>\n<\/div>\n\n
\ntype ProductServiceImpl struct {\r\n\tproductDAO persist.ProductDAO\r\n}\r\n\r\n\/\/ Constructor\r\nfunc NewProductServiceImpl(dao persist.ProductDAO) *ProductServiceImpl {\r\n\treturn &ProductServiceImpl{\r\n\t\tproductDAO: dao,\r\n\t}\r\n}\r\n\r\nfunc (s *ProductServiceImpl) IsProductReservable(id int) (bool, error) {\r\n\t\/\/ Produktinformation aus Datenbank holen\r\n\tproduct, err := s.productDAO.GetProduct(id)\r\n\tif err != nil {\r\n\t\treturn false, fmt.Errorf("failed to get product details: %w", err)\r\n\t}\r\n\r\n\tif product == nil {\r\n\t\treturn false, fmt.Errorf("product not found for id %v", id)\r\n\t}\r\n\r\n\t\/\/ Nur Produkte, die vor mehr als 1 Jahr in den Katalog aufgenommen wurden, k\u00f6nnen reserviert werden\r\n\treturn product.CreatedAt.Before(time.Now().AddDate(-1, 0, 0)), nil\r\n}<\/span><\/pre>\n<\/div>\nTestify verwenden<\/span><\/h2>\n
Assertions ausf\u00fchren<\/span><\/h3>\n
\nimport (\t\r\n\t"service"\r\n\t"testing"\r\n)\r\n\r\nfunc TestNewProductServiceImpl(t *testing.T) {\r\n\tproductDaoMock := ProductDaoMock{} \/\/ Mock vorerst ignorieren\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\t\/\/ Sichert ProductServiceImpl zu implementiert ProductService. Bricht den Compiler ab, wenn er es nicht tut.\r\n\tvar _ service.ProductService = productServiceImpl\r\n\r\n\tif productServiceImpl == nil {\r\n\t\tt.Fatal("Produktdienst nicht initialisiert")\r\n\t}\r\n\r\n\tif productServiceImpl.productDAO == nil {\r\n\t\tt.Fatal("Produktdienst-Abh\u00e4ngigkeit nicht initialisiert")\r\n\t}\r\n}<\/span><\/pre>\n<\/div>\ngithub.com\/stretchr\/testify\/assert<\/code>. Dieses Paket bietet mehrere Methoden, die helfen k\u00f6nnen, Werte mit erwarteten Ergebnissen zu vergleichen. Wenn wir unsere Vergleiche durch diese Methoden ersetzen, erhalten wir folgendes:<\/span><\/p>\n\nimport (\r\n\t"github.com\/stretchr\/testify\/assert"\r\n\t"service"\r\n\t"testing"\r\n)\r\n\r\nfunc TestNewProductServiceImpl(t *testing.T) {\r\n\tassertions := assert.New(t)\r\n\tproductDaoMock := ProductDaoMock{} \/\/ Mock vorerst ignorieren\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\tif !assertions.Implements((*service.ProductService)(nil), new(ProductServiceImpl)) {\r\n\t\tt.Fatal("Produktdienst-Implementierung beachtet Dienstdefinition nicht")\r\n\t}\r\n\r\n\tif !assertions.NotNil(productServiceImpl, "Produktdienst nicht initialisiert") {\r\n\t\tt.Fatal("Produktdienst nicht initialisiert")\r\n\t}\r\n\r\n\tif !assertions.NotNil(productServiceImpl.productDAO, "Produktdienst-Abh\u00e4ngigkeit nicht initialisiert") {\r\n\t\tt.Fatal("Produktdienst-Abh\u00e4ngigkeit nicht initialisiert")\r\n\t}\r\n}<\/span><\/pre>\n<\/div>\n=== RUN TestNewProductServiceImpl\r\n TestNewProductServiceImpl: product_service_impl_test.go:22:\r\n \tError Trace:\tproduct_service_impl_test.go:22\r\n \tError: \tErwarteter Wert darf nicht Null sein.\r\n \tTest: \tTestNewProductServiceImpl\r\n \tMeldungen: \tProduktdienst-Abh\u00e4ngigkeit nicht initialisiert\r\n TestNewProductServiceImpl: product_service_impl_test.go:23: Produktdienst-Abh\u00e4ngigkeit nicht initialisiert\r\n--- FAIL: TestNewProductServiceImpl (0.00s)<\/pre>\n
github.com\/stretchr\/testify\/require<\/code>. Dieses Paket verf\u00fcgt \u00fcber die gleichen Assertion-Methoden wie das assert-Paket, bricht aber den Test sofort ab, wenn eine Assertion fehlschl\u00e4gt. Wenn wir dieses Paket einf\u00fchren, erhalten wir den folgenden k\u00fcrzeren und leichter zu lesenden Testcode:<\/span><\/p>\n\nimport (\r\n\t"github.com\/stretchr\/testify\/require"\r\n\t"service"\r\n\t"testing"\r\n)\r\n\r\nfunc TestNewProductServiceImpl(t *testing.T) {\r\n\tassertions := require.New(t)\r\n\r\n\tproductDaoMock := ProductDaoMock{} \/\/ Mock vorerst ignorieren\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\tassertions.Implements((*service.ProductService)(nil), new(ProductServiceImpl), "Produktdienst-Implementierung beachtet Dienstdefinition nicht")\r\n\tassertions.NotNil(productServiceImpl, "Produktdienst nicht initialisiert")\r\n\tassertions.NotNil(productServiceImpl.productDAO, "Produktdienst-Abh\u00e4ngigkeit nicht initialisiert")\r\n}<\/span><\/pre>\n<\/div>\nMocking-Abh\u00e4ngigkeiten<\/span><\/h3>\n
\ntype ProductDAO interface {\r\n\tGetProduct(id int) (*model.Product, error)\r\n}<\/span><\/pre>\n<\/div>\n\nimport (\r\n\t"errors"\r\n\t"model"\r\n\t"persist"\r\n\t"testing"\r\n\t"time"\r\n)\r\n\r\ntype ProductDaoMock struct {\r\n}\r\n\r\nfunc (m *ProductDaoMock) GetProduct(id int) (*model.Product, error) {\r\n\tswitch id {\r\n\tcase 1:\r\n\t\treturn &model.Product{\r\n\t\t\tId: 1,\r\n\t\t\tDescription: "Produkt wurde vor 2 Jahren erstellt",\r\n\t\t\tCreatedAt: time.Now().AddDate(-2, 0, 0),\r\n\t\t}, nil\r\n\tcase 2:\r\n\t\treturn &model.Product{\r\n\t\t\tId: 2,\r\n\t\t\tDescription: "Produkt k\u00fcrzlich erstellt",\r\n\t\t\tCreatedAt: time.Now(),\r\n\t\t}, nil\r\n\tcase 999:\r\n\t\treturn nil, persist.ErrProductNotFound\r\n\t}\r\n\treturn nil, nil\r\n}\r\n\r\nfunc TestProductServiceImpl_IsProductReservable(t *testing.T) {\r\n\ttestDataSet := map[int]bool {\r\n\t\t1: true,\r\n\t\t2: false,\r\n\t}\r\n\r\n\tproductDaoMock := ProductDaoMock{}\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\tfor productId, expectedResult := range testDataSet {\r\n\t\treservable, err := productServiceImpl.IsProductReservable(productId)\r\n\t\tif err != nil {\r\n\t\t\tt.Fatalf("Es konnte nicht gepr\u00fcft werden, ob Produkt %v reservierbar ist: %s", productId, err)\r\n\t\t}\r\n\r\n\t\tif reservable != expectedResult {\r\n\t\t\tt.Fatalf("Falsche Reservierungsinfo f\u00fcr Produkt-ID erhalten %v. Expected: %v. Got: %v", productId, expectedResult, reservable)\r\n\t\t}\r\n\t}\r\n}\r\n\r\nfunc TestProductServiceImpl_IsProductReservable_NotFound(t *testing.T) {\r\n\tproductDaoMock := ProductDaoMock{}\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\t_, err := productServiceImpl.IsProductReservable(999)\r\n\tif !errors.Is(err, persist.ErrProductNotFound) {\r\n\t\tt.Fatalf("Unerwartetes Fehlerergebnis erhalten: %s", err)\r\n\t}\r\n}<\/span><\/pre>\n<\/div>\ngithub.com\/stretchr\/testify\/mock<\/code>. Dieses Paket stellt Tools zur Verf\u00fcgung, um Mocks zu erstellen, die es erm\u00f6glichen, das Verhalten zur Laufzeit zu injizieren. Dabei sorgt der Testfall selbst daf\u00fcr, dass die gemockte Logik nahe an der Testlogik bleibt.<\/span><\/p>\n\nimport (\r\n "github.com\/stretchr\/testify\/require"\r\n "github.com\/stretchr\/testify\/mock"\r\n\t"errors"\r\n\t"model"\r\n\t"persist"\t\r\n\t"testing"\r\n\t"time"\r\n)\r\n\r\ntype ProductDaoTestifyMock struct {\r\n\tmock.Mock\r\n}\r\n\r\nfunc (m *ProductDaoTestifyMock) GetProduct(id int) (*model.Product, error) {\r\n\targs := m.Called(id)\r\n\treturn args.Get(0).(*model.Product), args.Error(1)\r\n}\r\n\r\nfunc TestProductServiceImpl_IsProductReservable(t *testing.T) {\r\n\tassertions := require.New(t)\r\n\r\n\t\/\/ Register test mocks\r\n\tproductDaoMock := ProductDaoTestifyMock{}\r\n\tproductDaoMock.On("GetProduct", 1).Return(&model.Product{\r\n\t\tId: 1,\r\n\t\tDescription: "Produkt wurde vor 2 Jahren erstellt",\r\n\t\tCreatedAt: time.Now().AddDate(-2, 0, 0),\t\t\r\n\t}, nil)\r\n\tproductDaoMock.On("GetProduct", 2).Return(&model.Product{\r\n\t\tId: 2,\r\n\t\tDescription: "Produkt k\u00fcrzlich erstellt",\r\n\t\tCreatedAt: time.Now(),\r\n\t}, nil)\r\n\r\n\ttestDataSet := map[int]bool {\r\n\t\t1: true,\r\n\t\t2: false,\r\n\t}\r\n\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\tfor productId, expectedResult := range testDataSet {\r\n\t\treservable, err := productServiceImpl.IsProductReservable(productId)\r\n\t\tassertions.NoErrorf(err, "Konnte nicht pr\u00fcfen, ob Produkt %v reservierbar ist: %s", productId, err)\r\n\t\tassertions.Equalf(expectedResult, reservable, "Falsche Reservierungsinfo f\u00fcr Produkt-ID erhalten %v", productId)\r\n\t}\r\n}\r\n\r\nfunc TestProductServiceImpl_IsProductReservable_NotFound(t *testing.T) {\r\n\tassertions := require.New(t)\r\n\r\n\t\/\/ Register test mocks\r\n\tproductDaoMock := ProductDaoTestifyMock{}\r\n\tproductDaoMock.On("GetProduct", 1).Return((*model.Product)(nil), persist.ErrProductNotFound)\r\n\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\t_, err := productServiceImpl.IsProductReservable(1)\r\n\r\n\tif !errors.Is(err, persist.ErrProductNotFound) {\r\n\t\tassertions.Failf("Got unexpected error result", "Unerwartetes Fehlerergebnis erhalten: %s", err)\r\n\t}\r\n}<\/span><\/pre>\n<\/div>\nFazit<\/span><\/h2>\n
$ export GOPROXY=https:\/\/gocenter.io\r\n$ go get github.com\/stretchr\/testify<\/pre>\n