![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2020\/09\/22144542\/TestifyBlog-03.png\")
<\/p>\n<\/p>\n
MISE \u00c0 JOUR\u00a0: \u00c0 compter du 1er\u00a0mai\u00a02021, le d\u00e9p\u00f4t central GoCenter a \u00e9t\u00e9 mis hors service et toutes ses fonctionnalit\u00e9s seront obsol\u00e8tes. Pour en savoir plus sur la mise hors service des centres, lisez l'article de blog sur la d\u00e9pr\u00e9ciation<\/a><\/span><\/p>\n <\/p>\n <\/p>\n Chaque mois, GoCenter d\u00e9cerne aux modules les plus performants un <\/b>badge Gopher<\/b><\/a> qui reconna\u00eet leur r\u00e9ussite. Cet article mentionne quelques-uns de ces <\/b>meilleurs modules<\/b><\/a> et leur utilisation dans Go.<\/b><\/span><\/p>\n Tous les d\u00e9veloppeurs en ont vu, m\u00eame dans des programmes Golang bien structur\u00e9s\u00a0: des commentaires qui vous sugg\u00e8rent de ne pas toucher aux lignes de code, vu qu'elles semblent fonctionner par magie. Ces avertissements nous rendent timides, car nous craignons de casser quelque chose. Mais les applications doivent changer, s\u2019am\u00e9liorer et innover.<\/span><\/p>\n C\u2019est pour cela que les tests unitaires sont une partie essentielle du d\u00e9veloppement de logiciels. Ils aident les d\u00e9veloppeurs \u00e0 d\u00e9terminer si les petites parties de leur logiciel remplissent correctement la fonction pr\u00e9vue. Avec la quantit\u00e9 adapt\u00e9e de couverture de tests unitaires en place, les d\u00e9veloppeurs se sentent plus en confiance pour modifier leurs impl\u00e9mentations, et m\u00eame la r\u00e9usiner \u00e0 partir de z\u00e9ro. Ils savent en effet qu\u2019ils peuvent facilement v\u00e9rifier si la nouvelle version fonctionne toujours comme pr\u00e9vu.<\/span><\/p>\n L\u2019importance des tests unitaires et d\u2019un ensemble solide d\u2019outils dans le m\u00eame langage augmente parall\u00e8lement \u00e0 la complexit\u00e9 des logiciels. Un code de test offrant une bonne couverture pouvant \u00eatre volumineux, il doit \u00eatre aussi lisible et facile \u00e0 maintenir que le code du produit, afin d'encourager les d\u00e9veloppeurs \u00e0 l\u2019utiliser et \u00e0 en tirer parti.<\/span><\/p>\n Pour nos projets de communaut\u00e9 Go tels que GoCenter, nous utilisons beaucoup le module <\/span><\/span>Testify, tr\u00e8s appr\u00e9ci\u00e9. Il fournit un ensemble de packages Golang pour r\u00e9aliser des fonctions de test unitaire essentielles.\u00a0<\/span><\/p>\n Cet article vous montre comment vous pouvez utiliser les principales fonctionnalit\u00e9s de Testify pour \u00e9crire des tests unitaires dans Go, faciles \u00e0 lire et \u00e0 maintenir. Vous verrez \u00e0 quoi ressembleraient les tests unitaires avec l\u2019utilisation de Go uniquement, d\u00e9couvrirez les packages de Testify qui peuvent vous aider concernant la t\u00e2che effectu\u00e9e, puis le code r\u00e9sultant apr\u00e8s l\u2019adoption de Testify. Nous allons vous montrer quelques meilleures pratiques pour effectuer des assertions et \u00e9crire des mocks pour les d\u00e9pendances.<\/span><\/p>\n Testify<\/b> est un ensemble de packages convivial pour les d\u00e9veloppeurs. Il poss\u00e8de plus de 11\u00a0000\u00a0\u00e9toiles sur GitHub et b\u00e9n\u00e9ficie d\u2019un excellent support communautaire. Testify \u00e9tend le cadre Ces fonctionnalit\u00e9s, en plus de la confiance quotidienne de notre \u00e9quipe communautaire Go, expliquent en grande partie pourquoi le module Testify est reconnu en tant que <\/span>\u00ab\u00a0Top Gopher\u00a0\u00bb dans GoCenter<\/span><\/a>. Si vous consultez les m\u00e9tadonn\u00e9es compl\u00e8tes de GoCenter sur le module Testify, <\/span>vous comprendrez pourquoi\u00a0:<\/p>\n<\/div>\n Pour commencer \u00e0 \u00e9crire les tests unitaires, nous avons tout d'abord besoin d\u2019un composant \u00e0 tester. Pour cet exercice, nous allons utiliser la d\u00e9finition de service suivante\u00a0:<\/span><\/p>\n <\/p>\n Pour cette d\u00e9finition de service, nous avons une impl\u00e9mentation que nous souhaitons tester. L\u2019impl\u00e9mentation ob\u00e9it \u00e0 une logique m\u00e9tier pour d\u00e9terminer si un produit est r\u00e9servable ou non. L\u2019impl\u00e9mentation s'appuie \u00e9galement sur un composant Objet d\u2019acc\u00e8s aux donn\u00e9es pour fournir des informations sur les produits. L\u2019impl\u00e9mentation doit r\u00e9ussir les cas de test simplifi\u00e9s suivants\u00a0:<\/span><\/p>\n L\u2019impl\u00e9mentation du service ressemble \u00e0 ce qui suit\u00a0:<\/span><\/p>\n Maintenant que nous disposons d\u2019un service simple, nous pouvons utiliser Testify pour cr\u00e9er des tests unitaires qui garantissent qu\u2019il fonctionne comme pr\u00e9vu.<\/span><\/p>\n Les t\u00e2ches les plus \u00e9l\u00e9mentaires effectu\u00e9es par les tests unitaires sont des assertions. Les assertions permettent g\u00e9n\u00e9ralement de v\u00e9rifier si les actions effectu\u00e9es par le test \u00e0 l\u2019aide d\u2019une entr\u00e9e d\u00e9termin\u00e9e produisent la sortie attendue. Elles peuvent \u00e9galement \u00eatre utilis\u00e9es pour v\u00e9rifier si les composants suivent les r\u00e8gles de conception souhait\u00e9es.\u00a0<\/span><\/p>\n En utilisant Go uniquement pour ex\u00e9cuter les assertions n\u00e9cessaires pour v\u00e9rifier si le premier cas de test est respect\u00e9 et si notre impl\u00e9mentation de service est initialis\u00e9e correctement, nous obtenons le code suivant\u00a0:<\/span><\/p>\n Pour aider avec les assertions, Testify fournit un package\u00a0 <\/span> En plus d\u2019aider avec les assertions, les packages Testify fournissent \u00e9galement une meilleure information lorsque l\u2019une de ces op\u00e9rations \u00e9choue. Par exemple, si nous avons oubli\u00e9 de d\u00e9finir le champ productDAO dans le constructeur d\u2019impl\u00e9mentation de service, nous obtenons l\u2019\u00e9chec de test suivant\u00a0:<\/span><\/p>\n Jusqu\u2019\u00e0 pr\u00e9sent, m\u00eame si nous disposons d\u2019une meilleure information et de m\u00e9thodes plus pratiques pour ex\u00e9cuter les assertions, nous ne pouvions pas r\u00e9duire la taille de notre test. Nous avons toujours un mod\u00e8le r\u00e9p\u00e9titif if-not-assertion-break, qui peut rendre plus difficile la lecture de notre code de test. Testify fournit un package pour faciliter ce point <\/span> <\/p>\n Lors du test d\u2019un composant, nous devons id\u00e9alement l\u2019isoler compl\u00e8tement pour \u00e9viter d\u2019avoir des \u00e9checs ailleurs qui compromettraient nos tests. Cela est particuli\u00e8rement difficile lorsque le composant que nous voulons tester a des d\u00e9pendances sur d\u2019autres composants depuis diff\u00e9rentes couches de notre logiciel. Dans le sc\u00e9nario que nous utilisons ici, notre impl\u00e9mentation de service repose sur un composant de la couche DAO (Data Access Object, Objet d'acc\u00e8s aux donn\u00e9es) pour acc\u00e9der aux informations sur les produits.<\/span><\/p>\n Pour promouvoir l\u2019isolation souhait\u00e9e, il est courant que les d\u00e9veloppeurs \u00e9crivent de fausses impl\u00e9mentations simplifi\u00e9es de ces d\u00e9pendances, \u00e0 utiliser pendant les tests. Ces fausses impl\u00e9mentations sont nomm\u00e9es mocks.<\/span><\/p>\n Nous pouvons cr\u00e9er une impl\u00e9mentation fictives du ProductDAO \u00e0 injecter dans l\u2019impl\u00e9mentation du service pour l\u2019ex\u00e9cution du test. L\u2019interface ProductDAO que notre mock doit impl\u00e9menter ressemble \u00e0 ce qui suit\u00a0:<\/span><\/p>\n Pour permettre l\u2019ex\u00e9cution du test, il est n\u00e9cessaire que le mock fournisse un comportement compatible avec tous les cas de test que nous voulons valider. Sinon, nous ne pouvons pas atteindre la couverture de test souhait\u00e9e. En utilisant Go uniquement, notre cas de test avec le mock ressemblerait \u00e0 ce qui suit\u00a0:<\/span><\/p>\n <\/p>\n Le principal probl\u00e8me avec l\u2019approche ci-dessus est que notre logique de cas de test est d\u00e9sormais distribu\u00e9e. Une partie de celle-ci est impl\u00e9ment\u00e9e dans le cas de test lui-m\u00eame, o\u00f9 nous envoyons des \u00e9v\u00e9nements au composant test\u00e9 et ex\u00e9cutons des assertions avec les r\u00e9sultats. L\u2019autre partie est impl\u00e9ment\u00e9e dans le mock, qui doit fournir un comportement compatible avec les tests r\u00e9alis\u00e9s par le cas de test. Il est facile de voir comment notre cas de test pourrait s\u2019interrompre, non pas en raison d\u2019un probl\u00e8me dans le test lui-m\u00eame, mais parce que le mock ne retourne pas les donn\u00e9es requises.\u00a0<\/span><\/p>\n Un autre probl\u00e8me qui peut le rendre encore plus frustrant est que nous partageons \u00e9galement le mock entre plusieurs cas de test. Il est possible que les modifications appliqu\u00e9es au mock pour qu'il satisfasse un cas de test en interrompent d\u2019autres. Dans notre sc\u00e9nario, seuls 3\u00a0cas de test qui nous int\u00e9ressent, mais vous pouvez imaginer \u00e0 quel point cela pourrait devenir compliqu\u00e9 si nous avions des cas de test plus complexes. Diviser le mock en plusieurs mocks ne serait pas non plus forc\u00e9ment utile, et pourrait potentiellement aggraver la situation en r\u00e9pandant encore davantage la complexit\u00e9. De plus, si notre interface fictive change, nous devons mettre \u00e0 jour plusieurs mocks pour qu'ils restent compatibles.<\/span><\/p>\n Nous devons garder la logique du cas de test centralis\u00e9e et ind\u00e9pendante. Testify fournit un package pour faciliter ce point <\/span> En utilisant le package fictif Testify pour cr\u00e9er notre mock DAO et en d\u00e9pla\u00e7ant l\u2019initialisation du comportement fictif vers les cas de test, ainsi qu\u2019en ajoutant le package Testify requis pour ex\u00e9cuter nos assertions, notre code de test ressemble \u00e0 ce qui suit\u00a0:<\/span><\/p>\n Dans l\u2019impl\u00e9mentation ci-dessus, notez comment le comportement fictif et la logique de test sont tous deux centralis\u00e9s dans le cas de test. Notez \u00e9galement comment le comportement fictif enregistr\u00e9 est exclusif au cas de test o\u00f9 il est plac\u00e9, car il appartient \u00e0 une instance fictive unique qui n\u2019est pas partag\u00e9e entre plusieurs tests. Les tests enregistrent m\u00eame des comportements diff\u00e9rents pour l\u2019ID de produit\u00a01 sans aucun probl\u00e8me. ProductDaoTestifyMock peut \u00eatre r\u00e9utilis\u00e9 en toute s\u00e9curit\u00e9 entre plusieurs cas de test, car il n\u2019a aucun comportement.<\/span><\/p>\n J\u2019esp\u00e8re que vous avez trouv\u00e9 des informations utiles dans cet article et qu\u2019il pourra vous aider \u00e0 cr\u00e9er de meilleurs tests unitaires dans vos projets. Pour ajouter Testify \u00e0 votre projet \u00e0 l\u2019aide des modules Go et commencer \u00e0 vous amuser avec, ex\u00e9cutez simplement les commandes suivantes\u00a0:<\/span><\/p>\n Consultez Testify sur GoCenter<\/span> ou faites des recherches pour d\u00e9couvrir encore plus de modules Go tr\u00e8s int\u00e9ressants.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":" MISE \u00c0 JOUR\u00a0: \u00c0 compter du 1er\u00a0mai\u00a02021, le d\u00e9p\u00f4t central GoCenter a \u00e9t\u00e9 mis hors service et toutes ses fonctionnalit\u00e9s seront obsol\u00e8tes. Pour en savoir plus sur la mise hors service des centres, lisez l'article de blog sur la d\u00e9pr\u00e9ciation Chaque mois, GoCenter d\u00e9cerne aux modules les plus performants un badge Gopher qui …<\/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":[9960,9397],"tags":[9402,9398,9399],"class_list":["post-80093","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-gestion-des-artefacts","category-go","tag-go-fr","tag-modules-go","tag-gocenter-fr"],"yoast_head":"\nTestify\u00a0: Un \u00ab\u00a0Top Gopher\u00a0\u00bb<\/span><\/h2>\n
de tests<\/code> l\u00e9ger de Go pour effectuer des assertions et des d\u00e9pendances fictives.<\/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>\nUne Unit\u00e9 GoLang Simple<\/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\/\/ Get product information from database\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\/\/ Only products added more than 1 year ago to the catalog can be reserved\r\n\treturn product.CreatedAt.Before(time.Now().AddDate(-1, 0, 0)), nil\r\n}<\/span><\/pre>\n<\/div>\nUtilisation de Testify<\/span><\/h2>\n
Ex\u00e9cution d\u2019Assertions<\/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{} \/\/ Ignorer le mock pour l'instant\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\t\/\/ Asserts ProductServiceImpl implements ProductService. Will break the compiler if it does not.\r\n\tvar _ service.ProductService = productServiceImpl\r\n\r\n\tif productServiceImpl == nil {\r\n\t\tt.Fatal("Product Service not initialized")\r\n\t}\r\n\r\n\tif productServiceImpl.productDAO == nil {\r\n\t\tt.Fatal("Product Service dependency not initialized")\r\n\t}\r\n}<\/span><\/pre>\n<\/div>\ngithub.com\/stretchr\/testify\/assert<\/code>. Ce package poss\u00e8de plusieurs m\u00e9thodes qui peuvent aider \u00e0 comparer les valeurs par rapport aux r\u00e9sultats attendus. Si nous rempla\u00e7ons nos comparaisons par ces m\u00e9thodes, nous obtenons le r\u00e9sultat suivant\u00a0:<\/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{} \/\/ Ignorer le mock pour l'instant\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\tif !assertions.Implements((*service.ProductService)(nil), new(ProductServiceImpl)) {\r\n\t\tt.Fatal("Product Service Implementation does not honor service definition")\r\n\t}\r\n\r\n\tif !assertions.NotNil(productServiceImpl, "Product Service not initialized") {\r\n\t\tt.Fatal("Product Service not initialized")\r\n\t}\r\n\r\n\tif !assertions.NotNil(productServiceImpl.productDAO, "Product Service dependency not initialized") {\r\n\t\tt.Fatal("Product Service dependency not initialized")\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: \tExpected value not to be nil.\r\n \tTest: \tTestNewProductServiceImpl\r\n \tMessages: \tProduct Service dependency not initialized\r\n TestNewProductServiceImpl: product_service_impl_test.go:23: Product Service dependency not initialized\r\n--- FAIL: TestNewProductServiceImpl (0.00s)<\/pre>\n
github.com\/stretchr\/testify\/require<\/code>. Ce package poss\u00e8de les m\u00eames m\u00e9thodes d\u2019assertion fournies par le package d\u2019assertion, mais il interrompt le test imm\u00e9diatement lorsqu\u2019une assertion \u00e9choue. En introduisant ce package, nous obtenons le code de test suivant, plus court et plus facile \u00e0 lire\u00a0:<\/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{} \/\/ Ignorer le mock pour l'instant\r\n\tproductServiceImpl := NewProductServiceImpl(&productDaoMock)\r\n\r\n\tassertions.Implements((*service.ProductService)(nil), new(ProductServiceImpl), "Product Service Implementation does not honor service definition")\r\n\tassertions.NotNil(productServiceImpl, "Product Service not initialized")\r\n\tassertions.NotNil(productServiceImpl.productDAO, "Product Service dependency not initialized")\r\n}<\/span><\/pre>\n<\/div>\nMocking de D\u00e9pendances<\/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: "Product created 2 years ago",\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: "Product recently created",\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("Failed to check if product %v is reservable: %s", productId, err)\r\n\t\t}\r\n\r\n\t\tif reservable != expectedResult {\r\n\t\t\tt.Fatalf("Got wrong reservable info for product id %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("Got unexpected error result: %s", err)\r\n\t}\r\n}<\/span><\/pre>\n<\/div>\ngithub.com\/stretchr\/testify\/mock<\/code>. Ce package fournit des outils pour cr\u00e9er des mocks qui permettent d\u2019injecter le comportement dans l\u2019ex\u00e9cution, ce qui permet au cas de test de le faire. La logique fictive reste ainsi proche de la logique du test.<\/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: "Product created 2 years ago",\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: "Product recently created",\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,"Failed to check if product %v is reservable: %s", productId, err)\r\n\t\tassertions.Equalf(expectedResult, reservable,"Got wrong reservable info for product id %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", "Got unexpected error result: %s", err)\r\n\t}\r\n}<\/span><\/pre>\n<\/div>\nConclusion<\/span><\/h2>\n
$ export GOPROXY=https:\/\/gocenter.io\r\n$ go get github.com\/stretchr\/testify<\/pre>\n