Im sorry then - I just assumed the tool would exclude or note the difference
there. Personally code test coverage I take with a grain of salt because most
people can’t write correct tests to begin with, so I’m almost always looking as
tests in the low level packages that are used upstream.
> O
But they are callable - I'm only doing this for exported functions and
methods - as I described in the initial post (and the implementation).
On Wednesday, 18 March 2020 15:15:30 UTC+1, Robert Engels wrote:
>
> Exactly, but unless those functions are externally callable there is no
> reason to t
Exactly, but unless those functions are externally callable there is no reason
to test them in isolation.
> On Mar 18, 2020, at 9:04 AM, Ondrej wrote:
>
>
> That omission is not really relevant. Even if I included an assertion in the
> test, it wouldn't affect the point I am making. I just
That omission is not really relevant. Even if I included an assertion in
the test, it wouldn't affect the point I am making. I just wanted to have
at least some source code to reproduce the problem - adding if
Calculator(1,2) != 3 {t.Error(...)} would make it more of a complete test,
but my poi
It’s because you are not writing the top level test correctly - there is no
testing at all !
> On Mar 18, 2020, at 7:02 AM, Ondrej wrote:
>
>
> Hey!
>
> There's an issue I've been grappling with for ages - say I have a custom
> function, Print, that calls six other functions, FormatString,
Hey!
There's an issue I've been grappling with for ages - say I have a custom
function, Print, that calls six other functions, FormatString, FormatBool,
FormatXYZ, ..., and I have no tests. Once I write some basic tests for
Print, it does call some of the other functions and from looking at my
