[PATCH v2] kernel32/tests: Add more tests for GetConsoleFontInfo

[Hugh McMaster]

On Friday, 29 April 2016 11:07 PM, Sebastian Lackner wrote:

On 29.04.2016 13:29, Hugh McMaster wrote:
>>      SetLastError(0xdeadbeef);
>>      ret = pGetConsoleFontInfo(NULL, FALSE, 0, cfi);
>>      ok(!ret, "got %d, expected zero\n", ret);
>>      todo_wine ok(GetLastError() == ERROR_INVALID_HANDLE, "got %u, expected 6\n", GetLastError());
>> +    ok(!cfi[0].nFont, "got %d, expected 0\n", cfi[0].nFont);
>> +    ok(!cfi[0].dwFontSize.X, "got %d, expected 0\n", cfi[0].dwFontSize.X);
>> +    ok(!cfi[0].dwFontSize.Y, "got %d, expected 0\n", cfi[0].dwFontSize.Y);
>
> Those tests do not add much value. Without initializing cfi before each call,
> its impossible to tell if GetConsoleFontInfo() nulled the struct or if it wasn't
> touched at all. However, I'm also not sure if we have to care about the struct
> content in case of a failure.

The values in the struct weren't altered from zero after the first failed call. But I take your point.
I'll try memset-ing another value and checking the returned values.

>      for (i = 0; i < num_fonts; i++)
>      {
>          tmp_font = GetConsoleFontSize(std_output, cfi[i].nFont);
>          tmp_w = (double)orig_font.X / tmp_font.X * win_width;
>          tmp_h = (double)orig_font.Y / tmp_font.Y * win_height;
> -        ok(cfi[i].dwFontSize.X == tmp_w, "got %d, expected %d\n", cfi[i].dwFontSize.X, tmp_w);
> -        ok(cfi[i].dwFontSize.Y == tmp_h, "got %d, expected %d\n", cfi[i].dwFontSize.Y, tmp_h);
> +        todo_wine ok(cfi[i].dwFontSize.X == tmp_w, "got %d, expected %d\n", cfi[i].dwFontSize.X, tmp_w);
> +        todo_wine ok(cfi[i].dwFontSize.Y == tmp_h, "got %d, expected %d\n", cfi[i].dwFontSize.Y, tmp_h);

> As mentioned in one of the previous mails, I still think it would be useful to have a test like
> ok(cfi[i].nFont == i, "...\n"); to show that the elements are returned in sorted order, and that
> the font index matches the array index. Otherwise accessing by index (as done in the test above)
> would not work. Did you defer it to a later patch or was there anything unclear?

This was on my 'to do' list. Anyway, I've never seen behaviour to suggest the elements aren't
sorted, but I'll add the test to each loop to make certain.