[PATCH v2] shlwapi/tests: Document where SHFormatDateTimeA() crashes for NULL pointers.
Saulius Krasuckas
saulius2 at ar-fi.lt
Thu Sep 2 05:26:02 CDT 2021
* On 2021-09-02 12:13, Huw Davies wrote:
> On Thu, Sep 02, 2021 at 11:44:36AM +0300, Saulius Krasuckas wrote:
>> I mean, if some questions arises about when that input pointer is
>> handled
>> (before other argument validation or maybe after that, or maybe at the
>> end),
>> the crash (and maybe additional crashes) would give some insights
>> about the
>> original algorithm.
>
> Which is exactly why you should *not* write these sort of tests.
Huw, I disagree that there can be a wrong sort of tests in black-box
testing. Really don't see this.
> We're aiming to match the functionality of the API without copying its
> implementation. We don't want to know about its internal branching
> structure.
And I aim at the functionality too: not the implementation, but the
exactness of the behavior.
IMO, it would be quite difficult to always ensure the project does the
same function in the very different way. Difficult to prove and
unnecessary. Because this is a black-box. Do I get this wrong?
Plus, in case a developer starts being afraid that one or another test
would reveal some unavoidable details of the original
function/algorithm, one could quickly get lost in the doubt and start
dropping every second ok-check in the area. Which would be a disaster
for a black-box testing.
I don't think these two things can be easily decoupled (even if the
original implementation goes open source, even with the compatible
license) or is it necessary at all. Just a PoV.
> Of course if a particular app depends on Windows returning a specific
> error code then thats the time to add a test for it.
OK. And leaving the disabled test code only helps to do that (for
everyone in doubt).
I still saw no harm in that code.
S.
PS. As the removal patch already got accepted, I hope no one minds my
response. :)
More information about the wine-devel
mailing list