Bug 91983

Summary: [EFL][WK2] Add unit tests for custom text encoding setting
Product: WebKit Reporter: Sudarsana Nagineni (babu) <naginenis>
Component: WebKit EFLAssignee: Sudarsana Nagineni (babu) <naginenis>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, gyuyoung.kim, lucas.de.marchi, sw0524.lee, tmpsantos, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description Sudarsana Nagineni (babu) 2012-07-23 04:50:14 PDT
Add unit tests for custom text encoding setting.
Comment 1 Sudarsana Nagineni (babu) 2012-07-23 05:24:25 PDT
Created attachment 153781 [details]
Patch
Comment 2 Sudarsana Nagineni (babu) 2012-07-23 13:22:17 PDT
Created attachment 153850 [details]
Patch

Add unit tests for set/get custom text encoding.
Comment 3 Chris Dumez 2012-07-23 13:26:22 PDT
Comment on attachment 153850 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153850&action=review

> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:39
> +    ASSERT_STREQ(ewk_view_setting_encoding_custom_get(webView()), 0);

Should we really use ASSERT_STREQ() for 0? Why not use ASSERT_FALSE(ewk_view_setting_encoding_custom_get(webView())); ?

> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:40
> +    ewk_view_setting_encoding_custom_set(webView(), "UTF-8");

Would be nice to test the return value.

> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:43
> +    ewk_view_setting_encoding_custom_set(webView(), 0);

Ditto.

> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:44
> +    ASSERT_STREQ(ewk_view_setting_encoding_custom_get(webView()), 0);

Should we really use ASSERT_STREQ() for 0? Why not use ASSERT_FALSE(ewk_view_setting_encoding_custom_get(webView())); ?
Comment 4 Sudarsana Nagineni (babu) 2012-07-23 14:02:07 PDT
Comment on attachment 153850 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153850&action=review

>> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:39
>> +    ASSERT_STREQ(ewk_view_setting_encoding_custom_get(webView()), 0);
> 
> Should we really use ASSERT_STREQ() for 0? Why not use ASSERT_FALSE(ewk_view_setting_encoding_custom_get(webView())); ?

ASSERT_FALSE also works in this case, but is there anything wrong in using ASSERT_STREQ() here? *_get() returns a C string and I want to assert if C string is NULL(like explained in docs ASSERT_STREQ(NULL, c_string)). But, style checker pushed me to use 0 instead of NULL.

>> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:40
>> +    ewk_view_setting_encoding_custom_set(webView(), "UTF-8");
> 
> Would be nice to test the return value.

I wonder how much it makes sense to test the return value of set function, because it returns always true(except in case of invalid input arg). That's the reason I am calling get immediately after set and comparing the C string.
Comment 5 Chris Dumez 2012-07-23 14:14:08 PDT
Comment on attachment 153850 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153850&action=review

>>> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:39
>>> +    ASSERT_STREQ(ewk_view_setting_encoding_custom_get(webView()), 0);
>> 
>> Should we really use ASSERT_STREQ() for 0? Why not use ASSERT_FALSE(ewk_view_setting_encoding_custom_get(webView())); ?
> 
> ASSERT_FALSE also works in this case, but is there anything wrong in using ASSERT_STREQ() here? *_get() returns a C string and I want to assert if C string is NULL(like explained in docs ASSERT_STREQ(NULL, c_string)). But, style checker pushed me to use 0 instead of NULL.

I don't know if it's wrong but at least it is confusing.

>>> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:40
>>> +    ewk_view_setting_encoding_custom_set(webView(), "UTF-8");
>> 
>> Would be nice to test the return value.
> 
> I wonder how much it makes sense to test the return value of set function, because it returns always true(except in case of invalid input arg). That's the reason I am calling get immediately after set and comparing the C string.

Well, better safe than sorry. Just because the current implementation always returns TRUE, does not mean the code will stay this way. It is always a good idea to test as much as possible. In this case, it is very easy to add an ASSERT_TRUE() and make sure the return value is really true (and stays that way in the future).
Comment 6 Sudarsana Nagineni (babu) 2012-07-23 14:31:35 PDT
Comment on attachment 153850 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=153850&action=review

>>>> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_view.cpp:40
>>>> +    ewk_view_setting_encoding_custom_set(webView(), "UTF-8");
>>> 
>>> Would be nice to test the return value.
>> 
>> I wonder how much it makes sense to test the return value of set function, because it returns always true(except in case of invalid input arg). That's the reason I am calling get immediately after set and comparing the C string.
> 
> Well, better safe than sorry. Just because the current implementation always returns TRUE, does not mean the code will stay this way. It is always a good idea to test as much as possible. In this case, it is very easy to add an ASSERT_TRUE() and make sure the return value is really true (and stays that way in the future).

Yes, it is easy to add and I don't mind adding, but I'm just trying to understand the real use of it with the current implementation. Isn't it true that we should update the test code when we change the APIs implementation?
Comment 7 Sudarsana Nagineni (babu) 2012-07-23 15:17:18 PDT
Created attachment 153874 [details]
Patch

Fix review comment #3.
Comment 8 Gyuyoung Kim 2012-07-23 18:55:35 PDT
Comment on attachment 153874 [details]
Patch

LGTM.
Comment 9 WebKit Review Bot 2012-07-24 15:54:23 PDT
Comment on attachment 153874 [details]
Patch

Clearing flags on attachment: 153874

Committed r123545: <http://trac.webkit.org/changeset/123545>
Comment 10 WebKit Review Bot 2012-07-24 15:54:28 PDT
All reviewed patches have been landed.  Closing bug.