История изменений

Никто не утверждал, что assert не нужен, просто в стандартную библиотеку не засунули ничего такого.

Ниже цитата из книги The Go Programming Language от Kernighan-а (11.2.5):

Many newcomers to Go are surprised by the minimalism of Go’s testing framework. Other languages’ frameworks provide mechanisms for identifying test functions (often using reflec- tion or metadata), hooks for performing ‘‘setup’’ and ‘‘teardown’’ operations before and after the tests run, and libraries of utility functions for asserting common predicates, comparing values, formatting error messages, and aborting a failed test (often using exceptions). Although these mechanisms can make tests very concise, the resulting tests often seem like they are written in a foreign language. Furthermore, although they may report PASS or FAIL correctly, their manner may be unfriendly to the unfortunate maintainer, with cryptic failure messages like «assert: 0 == 1» or page after page of stack traces.

Go’s attitude to testing stands in stark contrast. It expects test authors to do most of this work themselves, defining functions to avoid repetition, just as they would for ordinary programs. The process of testing is not one of rote form filling; a test has a user interface too, albeit one whose only users are also its maintainers. A good test does not explode on failure but prints a clear and succinct description of the symptom of the problem, and perhaps other relevant facts about the context. Ideally, the maintainer should not need to read the source code to decipher a test failure. A good test should not give up after one failure but should try to report several errors in a single run, since the pattern of failures may itself be revealing.

…

The key to a good test is to start by implementing the concrete behavior that you want and only then use functions to simplify the code and eliminate repetition. Best results are rarely obtained by starting with a library of abstract, generic testing functions.

И далее приводят конкретный пример с assertEquals заменяя его на сравнение и утверждая, что получилось лучше. Я уж не буду всё копировать, PDF легко находится.

Поэтому я таки буду утверждать, что авторы языка намеренно не внесли эту функцию в стандартную библиотеку и намеренно рекомендуют не использовать дополнительных библиотек для этой функции. В крайнем случае написать эту функцию прямо по месту использования. Чего там можно в assertEquals не такого сделать-то… Я бы даже сказал, что сделав эту функцию магической её можно было бы сделать гораздо удобней. К примеру распечатать Assertion Failed: test_math.go:456: sqrt(2) (returns 5) != 4, т.е. текст выражения в ассерте, а не только его значение, которое доступно при обычной реализации.

Ещё могу заметить, что я читал, что в самом гугле в тестах запрещено использовать что-либо кроме стандартной библиотеки.

Никто не утверждал, что assert не нужен, просто в стандартную библиотеку не засунули ничего такого.

Ниже цитата из книги The Go Programming Language от Kernighan-а (11.2.5):

Many newcomers to Go are surprised by the minimalism of Go’s testing framework. Other languages’ frameworks provide mechanisms for identifying test functions (often using reflec- tion or metadata), hooks for performing ‘‘setup’’ and ‘‘teardown’’ operations before and after the tests run, and libraries of utility functions for asserting common predicates, comparing values, formatting error messages, and aborting a failed test (often using exceptions). Although these mechanisms can make tests very concise, the resulting tests often seem like they are written in a foreign language. Furthermore, although they may report PASS or FAIL correctly, their manner may be unfriendly to the unfortunate maintainer, with cryptic failure messages like «assert: 0 == 1» or page after page of stack traces.

Go’s attitude to testing stands in stark contrast. It expects test authors to do most of this work themselves, defining functions to avoid repetition, just as they would for ordinary programs. The process of testing is not one of rote form filling; a test has a user interface too, albeit one whose only users are also its maintainers. A good test does not explode on failure but prints a clear and succinct description of the symptom of the problem, and perhaps other relevant facts about the context. Ideally, the maintainer should not need to read the source code to decipher a test failure. A good test should not give up after one failure but should try to report several errors in a single run, since the pattern of failures may itself be revealing.

…

The key to a good test is to start by implementing the concrete behavior that you want and only then use functions to simplify the code and eliminate repetition. Best results are rarely obtained by starting with a library of abstract, generic testing functions.

И далее приводят конкретный пример с assertEquals заменяя его на сравнение и утверждая, что получилось лучше. Я уж не буду всё копировать, PDF легко находится.

Поэтому я таки буду утверждать, что авторы языка намеренно не внесли эту функцию в стандартную библиотеку и намеренно рекомендуют не использовать дополнительных библиотек для этой функции. В крайнем случае написать эту функцию прямо по месту использования.

Ещё могу заметить, что я читал, что в самом гугле в тестах запрещено использовать что-либо кроме стандартной библиотеки.

Никто не утверждал, что assert не нужен, просто в стандартную библиотеку не засунули ничего такого.

Ниже цитата из книги The Go Programming Language от Kernighan-а (11.2.5):

Many newcomers to Go are surprised by the minimalism of Go’s testing framework. Other languages’ frameworks provide mechanisms for identifying test functions (often using reflec- tion or metadata), hooks for performing ‘‘setup’’ and ‘‘teardown’’ operations before and after the tests run, and libraries of utility functions for asserting common predicates, comparing values, formatting error messages, and aborting a failed test (often using exceptions). Although these mechanisms can make tests very concise, the resulting tests often seem like they are written in a foreign language. Furthermore, although they may report PASS or FAIL correctly, their manner may be unfriendly to the unfortunate maintainer, with cryptic failure messages like «assert: 0 == 1» or page after page of stack traces.

Go’s attitude to testing stands in stark contrast. It expects test authors to do most of this work themselves, defining functions to avoid repetition, just as they would for ordinary programs. The process of testing is not one of rote form filling; a test has a user interface too, albeit one whose only users are also its maintainers. A good test does not explode on failure but prints a clear and succinct description of the symptom of the problem, and perhaps other relevant facts about the context. Ideally, the maintainer should not need to read the source code to decipher a test failure. A good test should not give up after one failure but should try to report several errors in a single run, since the pattern of failures may itself be revealing.

И далее приводят конкретный пример с assertEquals заменяя его на сравнение и утверждая, что получилось лучше. Я уж не буду всё копировать, PDF легко находится.

Поэтому я таки буду утверждать, что авторы языка намеренно не внесли эту функцию в стандартную библиотеку и намеренно рекомендуют не использовать дополнительных библиотек для этой функции.

Ещё могу заметить, что я читал, что в самом гугле в тестах запрещено использовать что-либо кроме стандартной библиотеки.

Никто не утверждал, что assert не нужен, просто в стандартную библиотеку не засунули ничего такого.

Ниже цитата из книги The Go Programming Language от Kernighan-а (11.2.5):

Many newcomers to Go are surprised by the minimalism of Go’s testing framework. Other languages’ frameworks provide mechanisms for identifying test functions (often using reflec- tion or metadata), hooks for performing ‘‘setup’’ and ‘‘teardown’’ operations before and after the tests run, and libraries of utility functions for asserting common predicates, comparing values, formatting error messages, and aborting a failed test (often using exceptions). Although these mechanisms can make tests very concise, the resulting tests often seem like they are written in a foreign language. Furthermore, although they may report PASS or FAIL correctly, their manner may be unfriendly to the unfortunate maintainer, with cryptic failure messages like «assert: 0 == 1» or page after page of stack traces.

Go’s attitude to testing stands in stark contrast. It expects test authors to do most of this work themselves, defining functions to avoid repetition, just as they would for ordinary programs. The process of testing is not one of rote form filling; a test has a user interface too, albeit one whose only users are also its maintainers. A good test does not explode on failure but prints a clear and succinct description of the symptom of the problem, and perhaps other relevant facts about the context. Ideally, the maintainer should not need to read the source code to decipher a test failure. A good test should not give up after one failure but should try to report several errors in a single run, since the pattern of failures may itself be revealing.

И далее приводят конкретный пример с assertEquals заменяя его на сравнение и утверждая, что получилось лучше.

Поэтому я таки буду утверждать, что авторы языка намеренно не внесли эту функцию в стандартную библиотеку и намеренно рекомендуют не использовать дополнительных библиотек для этой функции.

Ещё могу заметить, что я читал, что в самом гугле в тестах запрещено использовать что-либо кроме стандартной библиотеки.