Unit tests for back-forward list API should be added.
Ideally the tests should land together with the feature (or at least be available for review). Are we going to see patches for this one coming soon?
(In reply to comment #1) > Ideally the tests should land together with the feature (or at least be available for review). Are we going to see patches for this one coming soon? Well, this would result in big patches. At least, with a bug report filed, we know the unit tests are coming.
(In reply to comment #2) > (In reply to comment #1) > > Ideally the tests should land together with the feature (or at least be available for review). Are we going to see patches for this one coming soon? > > Well, this would result in big patches. At least, with a bug report filed, we know the unit tests are coming. I'm fine with separated bugs, but they both should be posted for review at the same time. Otherwise it become a technical debt that who knows when it is going to be paid.
Created attachment 158895 [details] patch Returning of technical debt :-)
Comment on attachment 158895 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=158895&action=review > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:92 > + ASSERT_TRUE(currentItem == anotherCurrentItem); ASSERT_EQ()? > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:114 > + ASSERT_TRUE(previousItem == anotherPreviousItem); ASSERT_EQ(previousItem, anotherPreviousItem)? > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:140 > + ASSERT_TRUE(nextItem == anotherNextItem); Ditto. > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:162 > + ASSERT_TRUE(previousItem == anotherPreviousItem); Ditto. > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:165 > + ASSERT_TRUE(!nonExistingItem); ASSERT_FALSE(nonExistingItem)?
Comment on attachment 158895 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=158895&action=review I will look closer at this later, unfortunately it is quite late > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:81 > +TEST_F(EWK2UnitTestBase, ewk_back_forward_list_current_item_get) Why the 2, isnt it pretty obvious given the path that it is a webkit 2 test? thing or normally only prefixed ewk and WK. I also refer to the file name, it looks out of place > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:129 > + // Go back to Page1 Punctuation mark at end
Comment on attachment 158895 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=158895&action=review >> Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:81 >> +TEST_F(EWK2UnitTestBase, ewk_back_forward_list_current_item_get) > > Why the 2, isnt it pretty obvious given the path that it is a webkit 2 test? thing or normally only prefixed ewk and WK. I also refer to the file name, it looks out of place Regarding the file name, this is part of the guidelines for WebKit2-EFL unit tests (http://trac.webkit.org/wiki/EFLWebKitTests): "Add your test file at: Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_foobarnicator.cpp (the prefix is test_ewk2 and not test_ewk, this was done to avoid clashes with WK1 tests) "
Created attachment 159021 [details] patch v2 Chris, Kenneth thanks for review
Comment on attachment 159021 [details] patch v2 LGTM. Thanks.
Comment on attachment 159021 [details] patch v2 Attachment 159021 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13510975 New failing tests: http/tests/cache/post-redirect-get.php http/tests/cache/post-with-cached-subresources.php
Created attachment 159070 [details] Archive of layout-test-results from gce-cr-linux-07 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: gce-cr-linux-07 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment on attachment 158895 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=158895&action=review > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:100 > + WKEinaSharedString url1 = urlFromTitle(httpServer.get(), title1); why name url1 if the test has no url2? > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:125 > + WKEinaSharedString url2 = urlFromTitle(httpServer.get(), title2); where is url1?
(In reply to comment #12) > (From update of attachment 158895 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=158895&action=review > > > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:100 > > + WKEinaSharedString url1 = urlFromTitle(httpServer.get(), title1); > > why name url1 if the test has no url2? > > > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_back_forward_list.cpp:125 > > + WKEinaSharedString url2 = urlFromTitle(httpServer.get(), title2); > > where is url1? I just meant that url2 corresponds to title2 and same for url1 and title1.
(In reply to comment #10) > (From update of attachment 159021 [details]) > Attachment 159021 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/13510975 > > New failing tests: > http/tests/cache/post-redirect-get.php > http/tests/cache/post-with-cached-subresources.php Seems to be false positive, patch is adding unit test for EFL WK2 API unrelated to chromium.
Created attachment 159120 [details] to be landed Retry.
Comment on attachment 159120 [details] to be landed Clearing flags on attachment: 159120 Committed r125905: <http://trac.webkit.org/changeset/125905>
All reviewed patches have been landed. Closing bug.
Something wrong with test (or the API). It is not passing since it landed.
(In reply to comment #18) > Something wrong with test (or the API). It is not passing since it landed. I'm guessing because the dependency (Bug 94248) has not landed?
(In reply to comment #19) > (In reply to comment #18) > > Something wrong with test (or the API). It is not passing since it landed. > > I'm guessing because the dependency (Bug 94248) has not landed? Indeed. It landed now and tests are passing. Would be nice next time land the utest together or right after the patch it depends on.