PPAPI URLRequestInfo test: port NaCl version to ppapi_tests. Fix Var and Resource leaks.

PPAPI URLRequestInfo test: port NaCl version to ppapi_tests. Fix Var and Resource leaks.

I had to also port a couple of constants and helpers from native_client/ppapi_test_lib.

TEST=ui_tests
BUG=110242
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=119522

[bbudge, 2012-01-16 16:24:29]

Just a few comments. Thank you for doing this!

http://codereview.chromium.org/9174020/diff/3004/chrome/test/ui/ppapi_uitest.cc
File chrome/test/ui/ppapi_uitest.cc (right):

http://codereview.chromium.org/9174020/diff/3004/chrome/test/ui/ppapi_uitest....
chrome/test/ui/ppapi_uitest.cc:483: TEST_PPAPI_NACL_VIA_HTTP(URLRequest_Stress)
Each PPAPITest takes 10-20 seconds to run. Could we collapse the really basic
ones like Create, IsURLRequestInfo, and SetProperty into a single test, ala
ResourceArray_Basics, below?

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.cc
File ppapi/tests/test_url_request.cc (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:70: return EnsureRunningOverHTTP();
Shouldn't we return false here if we couldn't get the above interfaces?

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.h
File ppapi/tests/test_url_request.h (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.h:51: };
struct could be hidden in the .cc file.

[dmichael (off chromium), 2012-01-17 18:38:02]

mostly just nits.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.cc
File ppapi/tests/test_url_request.cc (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:55: if (!ppb_url_request_interface_)
optional: You could just do
ASSERT_TRUE(foo_interface_);
for these if you wanted. (or ASSERT_NEQ(NULL,...); if that doesn't work)

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:90: return "Create() passed with an invalid
instance";
nit: I prefer ASSERT_* for checks, unless what the macro would spit out is
ambiguous. I find the tests more readable that way. TestURLLoader is a bad
example :-)

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:137: #define TEST_BOOL(_name) \
nit: I think the style guide says that all precompiler directives should go at
the start of the line (i.e., no 2-space indent). There's also no point in having
it in the scope of the function. It doesn't hurt anything, so feel free to leave
it in there if you like, but be aware that precompiler directives don't respect
scope.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:250: i < sizeof(test_data) /
sizeof(PropertyTestData);
nit: best practice is to use sizeof(test_data[0]) in the denominator, in case
test_data's type changes.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:260: error = test_data[i].property_name;
FWIW, I think this is a perfect example where building a custom error string is
better than using the ASSERT_* macros. My suggestion about using ASSERT_*
doesn't apply here.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:262:
ppb_var_interface_->Release(test_data[i].var);
Ah, you can ignore my prior comment about releasing the var in the destructor,
if you want :-)

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.h
File ppapi/tests/test_url_request.h (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.h:42: PP_Var _var, PP_Bool _expected_value) :
Please don't use leading underscores in names. It's technically okay here, but
some kinds of names with leading underscores are reserved for use by the
compiler implementation. I think it's best just to avoid leading underscores
altogether.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.h:49: PP_Var var;
You *might* need your destructor to release this var. If it's a string, you
might leak it, and the test framework should complain and say the test failed.

The ref-counting semantics aren't obvious for PPB_URL It looks like since you
always pass the string immediately to a function on PPB_URLRequestInfo, but from
glancing at the code, it looks like it does not take ownership, so I think
you're responsible for releasing the parameter you send in :-/

[polina1, 2012-01-26 02:56:26]

http://codereview.chromium.org/9174020/diff/3004/chrome/test/ui/ppapi_uitest.cc
File chrome/test/ui/ppapi_uitest.cc (right):

http://codereview.chromium.org/9174020/diff/3004/chrome/test/ui/ppapi_uitest....
chrome/test/ui/ppapi_uitest.cc:483: TEST_PPAPI_NACL_VIA_HTTP(URLRequest_Stress)
On 2012/01/16 16:24:29, bbudge1 wrote:
> Each PPAPITest takes 10-20 seconds to run. Could we collapse the really basic
> ones like Create, IsURLRequestInfo, and SetProperty into a single test, ala
> ResourceArray_Basics, below?

I think it is a very good idea to combine the first two (and I did), but not
convinced that SetProperty should be merged as well. It pretty long and
detailed. And I think the whole point of separate test cases was to be able to
narrow things down and disable/enable them independently of the rest.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.cc
File ppapi/tests/test_url_request.cc (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:55: if (!ppb_url_request_interface_)
On 2012/01/17 18:38:03, dmichael wrote:
> optional: You could just do
> ASSERT_TRUE(foo_interface_);
> for these if you wanted. (or ASSERT_NEQ(NULL,...); if that doesn't work)

Not sure why that's better for init, but in either case it does not work. It is
translated into a std::string return, but this function returns bool (contrary
to all the test functions).

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:70: return EnsureRunningOverHTTP();
On 2012/01/16 16:24:29, bbudge1 wrote:
> Shouldn't we return false here if we couldn't get the above interfaces?

Just setting the error does the trick. That's how other Init's do it (e.g.
test_url_loader).

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:90: return "Create() passed with an invalid
instance";
On 2012/01/17 18:38:03, dmichael wrote:
> nit: I prefer ASSERT_* for checks, unless what the macro would spit out is
> ambiguous. I find the tests more readable that way. TestURLLoader is a bad
> example :-)

I think historically these tests were written not to use ASSERTs and EXPECTs. So
I just followed that, but I guess now we are converting to more gunit test
style?

Except in this test, because it is using the C interface, I sometimes need to
delay returning on an error to be able to release vars and resources. I can't do
that with ASSERTs, can I? And mixing the two styles throughout seems like it
would just create confusion. Thoughts?

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:137: #define TEST_BOOL(_name) \
On 2012/01/17 18:38:03, dmichael wrote:
> nit: I think the style guide says that all precompiler directives should go at
> the start of the line (i.e., no 2-space indent). There's also no point in
having
> it in the scope of the function. It doesn't hurt anything, so feel free to
leave
> it in there if you like, but be aware that precompiler directives don't
respect
> scope.

Yeah, I know. I wanted to keep the diff with the original NaCl function (not
written by me) to a minimum, so it is easy to see how the test was ported. So is
it OK to leave things as-is?

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:250: i < sizeof(test_data) /
sizeof(PropertyTestData);
On 2012/01/17 18:38:03, dmichael wrote:
> nit: best practice is to use sizeof(test_data[0]) in the denominator, in case
> test_data's type changes.

Done.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:260: error = test_data[i].property_name;
On 2012/01/17 18:38:03, dmichael wrote:
> FWIW, I think this is a perfect example where building a custom error string
is
> better than using the ASSERT_* macros. My suggestion about using ASSERT_*
> doesn't apply here.

Done.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:262:
ppb_var_interface_->Release(test_data[i].var);
On 2012/01/17 18:38:03, dmichael wrote:
> Ah, you can ignore my prior comment about releasing the var in the destructor,
> if you want :-)

I already responded to that comment before reading this, so I'll just leave the
reply in.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.h
File ppapi/tests/test_url_request.h (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.h:42: PP_Var _var, PP_Bool _expected_value) :
This was a port of the NaCl code. I am not too keen on these myself, so removed.

On 2012/01/17 18:38:03, dmichael wrote:
> Please don't use leading underscores in names. It's technically okay here, but
> some kinds of names with leading underscores are reserved for use by the
> compiler implementation. I think it's best just to avoid leading underscores
> altogether.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.h:49: PP_Var var;
There are no leaks because the var is released at the end of TestSetProperty.

The leaks are actually reported by the test framework. There used to be leaks in
the NaCl code because an additional var increment was done in the constructor. I
removed it and added a comment instead.

On 2012/01/17 18:38:03, dmichael wrote:
> You *might* need your destructor to release this var. If it's a string, you
> might leak it, and the test framework should complain and say the test failed.
> 
> The ref-counting semantics aren't obvious for PPB_URL It looks like since you
> always pass the string immediately to a function on PPB_URLRequestInfo, but
from
> glancing at the code, it looks like it does not take ownership, so I think
> you're responsible for releasing the parameter you send in :-/

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.h:51: };
On 2012/01/16 16:24:29, bbudge1 wrote:
> struct could be hidden in the .cc file.

done
moved to the same spot where it was in the NaCl code to minimize the diff

[dmichael (off chromium), 2012-01-26 17:13:43]

just nits, LGTM

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.cc
File ppapi/tests/test_url_request.cc (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:55: if (!ppb_url_request_interface_)
On 2012/01/26 02:56:26, polina1 wrote:
> On 2012/01/17 18:38:03, dmichael wrote:
> > optional: You could just do
> > ASSERT_TRUE(foo_interface_);
> > for these if you wanted. (or ASSERT_NEQ(NULL,...); if that doesn't work)
> 
> Not sure why that's better for init, but in either case it does not work. It
is
> translated into a std::string return, but this function returns bool (contrary
> to all the test functions).
Nevermind, wasn't reading carefully enough. Those don't make sense in Init.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:90: return "Create() passed with an invalid
instance";
On 2012/01/26 02:56:26, polina1 wrote:
> On 2012/01/17 18:38:03, dmichael wrote:
> > nit: I prefer ASSERT_* for checks, unless what the macro would spit out is
> > ambiguous. I find the tests more readable that way. TestURLLoader is a bad
> > example :-)
> 
> I think historically these tests were written not to use ASSERTs and EXPECTs.
So
> I just followed that, but I guess now we are converting to more gunit test
> style?
> 
> Except in this test, because it is using the C interface, I sometimes need to
> delay returning on an error to be able to release vars and resources. I can't
do
> that with ASSERTs, can I?
Right, only do them where they make sense.
> And mixing the two styles throughout seems like it
> would just create confusion. Thoughts?
>
I still prefer using the ASSERT style where it makes sense. In 101->107, for
example, the returned strings are very boilderplate. The ASSERT gives you all
the information you need in case of a failure, and I find it more readable. It's
not a huge deal here; the other URL tests don't use ASSERT yet. But I want us to
move towards the macros to make the tests more consistent & readable.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:137: #define TEST_BOOL(_name) \
On 2012/01/26 02:56:26, polina1 wrote:
> On 2012/01/17 18:38:03, dmichael wrote:
> > nit: I think the style guide says that all precompiler directives should go
at
> > the start of the line (i.e., no 2-space indent). There's also no point in
> having
> > it in the scope of the function. It doesn't hurt anything, so feel free to
> leave
> > it in there if you like, but be aware that precompiler directives don't
> respect
> > scope.
> 
> Yeah, I know. I wanted to keep the diff with the original NaCl function (not
> written by me) to a minimum, so it is easy to see how the test was ported. So
is
> it OK to leave things as-is?
How about just fixing the indentation so they are consistent with the style
guide? I don't think you need to move them out of the function body.

[bbudge, 2012-01-26 17:22:08]

LGTM. Thanks again Polina.

[polina1, 2012-01-26 21:26:58]

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.cc
File ppapi/tests/test_url_request.cc (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:90: return "Create() passed with an invalid
instance";
On 2012/01/26 17:13:43, dmichael wrote:
> On 2012/01/26 02:56:26, polina1 wrote:
> > On 2012/01/17 18:38:03, dmichael wrote:
> > > nit: I prefer ASSERT_* for checks, unless what the macro would spit out is
> > > ambiguous. I find the tests more readable that way. TestURLLoader is a bad
> > > example :-)
> > 
> > I think historically these tests were written not to use ASSERTs and
EXPECTs.
> So
> > I just followed that, but I guess now we are converting to more gunit test
> > style?
> > 
> > Except in this test, because it is using the C interface, I sometimes need
to
> > delay returning on an error to be able to release vars and resources. I
can't
> do
> > that with ASSERTs, can I?
> Right, only do them where they make sense.
> > And mixing the two styles throughout seems like it
> > would just create confusion. Thoughts?
> >
> I still prefer using the ASSERT style where it makes sense. In 101->107, for
> example, the returned strings are very boilderplate. The ASSERT gives you all
> the information you need in case of a failure, and I find it more readable.
It's
> not a huge deal here; the other URL tests don't use ASSERT yet. But I want us
to
> move towards the macros to make the tests more consistent & readable. 
> 

Done.

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:137: #define TEST_BOOL(_name) \
On 2012/01/26 17:13:43, dmichael wrote:
> On 2012/01/26 02:56:26, polina1 wrote:
> > On 2012/01/17 18:38:03, dmichael wrote:
> > > nit: I think the style guide says that all precompiler directives should
go
> at
> > > the start of the line (i.e., no 2-space indent). There's also no point in
> > having
> > > it in the scope of the function. It doesn't hurt anything, so feel free to
> > leave
> > > it in there if you like, but be aware that precompiler directives don't
> > respect
> > > scope.
> > 
> > Yeah, I know. I wanted to keep the diff with the original NaCl function (not
> > written by me) to a minimum, so it is easy to see how the test was ported.
So
> is
> > it OK to leave things as-is?
> How about just fixing the indentation so they are consistent with the style
> guide? I don't think you need to move them out of the function body.

I shifted #define to the very left to be consistent with the style guide
(although it was talking about #ifdef and such actually). And the rest is
shifted 4 spaces. The style guide did not talk about that, but I found an
example in the C++ primer.

[dmichael (off chromium), 2012-01-26 21:36:05]

LGTM, thank you!

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request.cc
File ppapi/tests/test_url_request.cc (right):

http://codereview.chromium.org/9174020/diff/3004/ppapi/tests/test_url_request...
ppapi/tests/test_url_request.cc:137: #define TEST_BOOL(_name) \
On 2012/01/26 21:26:59, polina1 wrote:
> On 2012/01/26 17:13:43, dmichael wrote:
> > On 2012/01/26 02:56:26, polina1 wrote:
> > > On 2012/01/17 18:38:03, dmichael wrote:
> > > > nit: I think the style guide says that all precompiler directives should
> go
> > at
> > > > the start of the line (i.e., no 2-space indent). There's also no point
in
> > > having
> > > > it in the scope of the function. It doesn't hurt anything, so feel free
to
> > > leave
> > > > it in there if you like, but be aware that precompiler directives don't
> > > respect
> > > > scope.
> > > 
> > > Yeah, I know. I wanted to keep the diff with the original NaCl function
(not
> > > written by me) to a minimum, so it is easy to see how the test was ported.
> So
> > is
> > > it OK to leave things as-is?
> > How about just fixing the indentation so they are consistent with the style
> > guide? I don't think you need to move them out of the function body.
> 
> I shifted #define to the very left to be consistent with the style guide
> (although it was talking about #ifdef and such actually). And the rest is
> shifted 4 spaces. The style guide did not talk about that, but I found an
> example in the C++ primer.
The style guide says "preprocessor directives", which includes #define. I think
4-space indent is what I'm used to seeing, too.