On Thu, Feb 4, 2021 at 4:35 PM Charles Hathaway
wrote:
> Hey all,
>
> Thomas, I agree that the code you provide would benefit from unit tests,
> but I would like to focus my question on the very common case which simply
> throws the error without additional edge cases, such as the example given
The case of somelib.Bar() can be solved by replacing it with an interface.
You can than inject a Bar function that always returns an error.
Otherwise I would recommend to use fuzzers to increase code coverage. They
will do a much better job than you do. For byte sequence interfaces that
don't
Hey all,
Thomas, I agree that the code you provide would benefit from unit tests,
but I would like to focus my question on the very common case which simply
throws the error without additional edge cases, such as the example given
in the first email.
Looking at the feedback given so far, I think
IMO:
To give these things names, you have:
func Foo(...) ..., error {
do things here...
err := makeASubroutineCall(...)
if err != nil {
return ..., err
}
do more things
}
And we suppose that makeASubroutineCall is already will tested and you know
it returns errors correctly. What
Good question and useful discussion!
What is Go community guidance on the _value_ of unit testing the `if err i=
nil { return err }` idiom?
To make the question a little more precise, let's consider the code snippet
in the first email in this thread. Let's assume that I already have
coverage
Hi,
On Tue, Dec 8, 2020 at 1:19 AM 'Charles Hathaway' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Hi all,
>
> I'm looking for a good study/quantitative measure of how well-written Go
> code looks compared to other languages, such as Java, when it comes to test
> coverage. In
Hi all,
I'm looking for a good study/quantitative measure of how well-written Go
code looks compared to other languages, such as Java, when it comes to test
coverage. In particular, how handling errors may reduce the percentage of
code covered by tests in Go relative to other languages.
For
