Say I wrote a function:
f(x::Float64) = sin(x) + 2
In terms of CI and test coverage, the code of this function has already been covered elsewhere (in Base). Shouldn’t it be possible for the CI process to “discover” that and mark it as (at least indirectly) tested? Or is this science fiction?
Everything boils down to a few assembler instructions in the end which are all “covered” just by building Julia. So we don’t have to test anything?
I’m assuming there is a continuum from impossible to automate to my example above. In the first case, automated tests would be a bad idea, but in the second case the automation wouldn’t do a worse job than what I’d be able to accomplish.
The fact that sin(x) + and 2 work individually doesn’t mean the behavior you get by composing them is what you want and that you didn’t accidentally introduce a bug here.
To make an analogy, even if you use perfect bricks, mortar, and wood, you can still make a bad house.
Presumably, you created f to have some “higher” purpose, that is what we want to test.
How would it know what f is supposed to do? Eg it could be that the “correct” function is f(x) = sin(x) - 2.
No idea. I thought it would be possible to see that f is equal to the sinus of x plus two. Decompose it to units of code that have already been tested. But it sounds like that it would either be impossible or unwise.
Sure, but how would the computer know that is the right thing. You are the only one who knows what higher level behavior you want from the function.
The point is that when writing tests for f it’s not only important that it runs, but also that it does what you want it to.
f(x::Int32) = "You're on a"*" 64bit system"
f(x::Int64) = "You're on a"*" 32bit system"
We know that string concatenation works, so the two functions would be covered by base tests, but it’s probably giving you the wrong result.
Now I get it. For some reason this really explained it to me. Thanks!