Ramkumar Ramachandra <artag...@gmail.com> writes:
> Junio C Hamano wrote:
>> Why two?
>
> What breaks checkout - is the initial HEAD detachment (which writes
> that "checkout: " message), before anything else happens. None of
> <onto>, <upstream>, and <branch> make any difference: I'm testing
> exactly the code that I patched.
>
> I have recently been told that I should be testing "end-user behavior"
> by treating the programs as black-boxes, instead of "implementation".
> What is your opinion on the issue? Should I write more tests?
Of course, the behaviours that should be observable by end-users
need be spelled out. Also, an impementation detail that cannot be
observed or make any difference to the end-user experience should
not be cast in stone.
The guideline is a good one, but you need to realize that there is a
difference between "do not test implementation details" and "do not
look at implementation when designing tests". Only the former is
necessary and correct: it lets you avoid over-specifying the
behaviour.
Sometimes you can trivially tell that some obvious implementations
that may be different from what you have can break the expectation
you are setting. For example, in v1.5.0, "rebase A B" literally ran
"git-checkout B" as the first thing, and if you want the end-user to
expect that @{-$n} does not resolve to B because such internal
"checkout" is not an user action, covering "rebase A B", even if you
know that the current implemention happens to be immune to such a
form of breakage, would be a good way to future-proof your code.
That still is testing the behaviour. You are just taking advantage
of the fact that you know the implementation and can anticipate how
future changes by careless people could break the behaviour.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
