)]}'
{"docs/testing-guidelines.md":[{"author":{"_account_id":7769,"name":"Pentheus","display_name":"Alan Meadows","email":"alan.meadows@gmail.com","username":"alanmeadows"},"change_message_id":"a688dd1d0231ed1315eaba63741ac17a997ecf9b","unresolved":false,"context_lines":[{"line_number":1,"context_line":"# Testing Guidelines"},{"line_number":2,"context_line":""},{"line_number":3,"context_line":"This document lays out several guidelines to secure high quality and"},{"line_number":4,"context_line":"consistency throughout `airshipctl`\u0027s test bed."}],"source_content_type":"text/x-markdown","patch_set":3,"id":"3fa7e38b_3871780d","line":1,"updated":"2019-10-09 08:57:22.000000000","message":"I have no issue with what this covers but should this also not cover some high level expectations for pkg (vs Cmd) tests as well? \n\n  - If I wanted to provide testdata that was unrelated to golden Cmd output, how would I do that?\n  - Am I encouraged to use subtests?\n  - When should I error vs fatal (too basic?)\n  - What kind of utilities are available for me in testutil/\n  - If I need to mock an API, what should I use?\n...","commit_id":"c63d4aea20575f2414135fb20cb3a93feae802c7"},{"author":{"_account_id":30797,"name":"kanwar saad bin liaqat","email":"kanwar.sbl@gmail.com","username":"ekanwli"},"change_message_id":"8bb7455e5fa302bfe36c21da8f93c625e26923de","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Golang provides a builtin `testing` package which supplies functions and"},{"line_number":9,"context_line":"objects which prove to be sufficient to test any Go program. Various projects"},{"line_number":10,"context_line":"in the Golang/Kubernetes community, such as Docker, Kubeadm, Helm, and"},{"line_number":11,"context_line":"Kustomize prefer it to third-party testing and mocking packages, so it would"},{"line_number":12,"context_line":"seem appropriate to stick to the trend."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"That said, the `airshipctl` project *does* allow the [testify] library, as it"}],"source_content_type":"text/x-markdown","patch_set":4,"id":"3fa7e38b_1839c0a2","line":11,"range":{"start_line":11,"start_character":47,"end_line":11,"end_character":63},"updated":"2019-10-15 12:24:30.000000000","message":"testing library is not used to mock packages. It is just for creating test fixtures.","commit_id":"4af56686ff71f0c667f8133e516cd84b6fe0c34c"},{"author":{"_account_id":30797,"name":"kanwar saad bin liaqat","email":"kanwar.sbl@gmail.com","username":"ekanwli"},"change_message_id":"8bb7455e5fa302bfe36c21da8f93c625e26923de","unresolved":false,"context_lines":[{"line_number":11,"context_line":"Kustomize prefer it to third-party testing and mocking packages, so it would"},{"line_number":12,"context_line":"seem appropriate to stick to the trend."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"That said, the `airshipctl` project *does* allow the [testify] library, as it"},{"line_number":15,"context_line":"serves as a thin wrapper around Go\u0027s builtin `testing` package, slightly"},{"line_number":16,"context_line":"reducing developer load."},{"line_number":17,"context_line":""}],"source_content_type":"text/x-markdown","patch_set":4,"id":"3fa7e38b_9814d045","line":14,"range":{"start_line":14,"start_character":53,"end_line":14,"end_character":63},"updated":"2019-10-15 12:24:30.000000000","message":"I guess it would lead to code having mix usage of standard testing library and testify. Probably sticking to stock testing package is good enough.\nTestify has 3 sub packages i.e assertions, mock and suite. It\u0027s better to clarify whether using suite subpackage is allowed or not because that will change the way how tests are written/structured. The functionality of mock and assertion library is really minimal. My suggestion is to select specialized libraries for each of these purposes. I would say, \u0027testify\u0027 don\u0027t do justice to any of these subtasks.","commit_id":"4af56686ff71f0c667f8133e516cd84b6fe0c34c"},{"author":{"_account_id":30797,"name":"kanwar saad bin liaqat","email":"kanwar.sbl@gmail.com","username":"ekanwli"},"change_message_id":"1cc5360f86da33c8869394f9b6ca47571587abc1","unresolved":false,"context_lines":[{"line_number":54,"context_line":"should be thought of as \"guidelines\" rather than \"rules\"."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"* Using [table-tests] prevents a lot of duplicated code."},{"line_number":57,"context_line":"* Using [subtests] allows tests to provide much more fine-grained results."},{"line_number":58,"context_line":"* Calls to `t.Fatal` should be reserved for situations in which the test should"},{"line_number":59,"context_line":"  fail immediately (e.g. during test setup). Generally, `t.Error` should be"},{"line_number":60,"context_line":"  preferred."}],"source_content_type":"text/x-markdown","patch_set":4,"id":"3fa7e38b_18ba20c0","line":57,"range":{"start_line":57,"start_character":2,"end_line":57,"end_character":25},"updated":"2019-10-15 12:31:49.000000000","message":"subtests are useful in table-driven tests but usually create a lot of clutter in code otherwise.","commit_id":"4af56686ff71f0c667f8133e516cd84b6fe0c34c"},{"author":{"_account_id":30797,"name":"kanwar saad bin liaqat","email":"kanwar.sbl@gmail.com","username":"ekanwli"},"change_message_id":"260ddc2da368c18ed8f9bdf9d50dcbaabbc9cef9","unresolved":false,"context_lines":[{"line_number":41,"context_line":"Test files end in `_test.go`, and sit next to the tested file. For example,"},{"line_number":42,"context_line":"`airshipctl/pkg/foo/foo.go` should be tested by"},{"line_number":43,"context_line":"`airshipctl/pkg/foo/foo_test.go`. Likewise, a test\u0027s package name should end"},{"line_number":44,"context_line":"in `_test`."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"Go will ignore any files stored in a directory called `testdata`, therefore all"},{"line_number":47,"context_line":"non-Go test files (such as expected output or example input) should be stored"}],"source_content_type":"text/x-markdown","patch_set":6,"id":"3fa7e38b_3a96be40","line":44,"range":{"start_line":44,"start_character":4,"end_line":44,"end_character":9},"updated":"2019-10-18 05:50:07.000000000","message":"Usually package name should be kept same for the unit tests. Because unit tests may want to test internal helper functions which are not exposed outside. For external package tests this requirement is ok.\nSo, should this be mandatory?","commit_id":"d90797cd5c3dbce2895a10f6bb9b6e1d1786b69a"}]}