fix #resource tag in browser tests

fix #resource tag in browser tests. Now ResourceTest passes :)

Committed: https://code.google.com/p/dart/source/detail?r=5166

[Emily Fortuna, 2012-02-23 00:41:02]

lgtm

[Ivan Posva, 2012-02-23 01:12:23]

https://chromiumcodereview.appspot.com/9448001/diff/1/tests/language/src/Reso...
File tests/language/src/ResourceTest.dart (right):

https://chromiumcodereview.appspot.com/9448001/diff/1/tests/language/src/Reso...
tests/language/src/ResourceTest.dart:5: #library('ResourceTest');
It would be preferable if the test harness would not just expect #library but
could add a #library if needed. Because as it stands now it is impossible to
test for correct handling of script files, which do not need to specify a
#library when using other library tags such as #import, #source or #resource.

[Jennifer Messerly, 2012-02-23 01:47:12]

On 2012/02/23 01:12:23, Ivan Posva wrote:
>
https://chromiumcodereview.appspot.com/9448001/diff/1/tests/language/src/Reso...
> File tests/language/src/ResourceTest.dart (right):
> 
>
https://chromiumcodereview.appspot.com/9448001/diff/1/tests/language/src/Reso...
> tests/language/src/ResourceTest.dart:5: #library('ResourceTest');
> It would be preferable if the test harness would not just expect #library but
> could add a #library if needed. Because as it stands now it is impossible to
> test for correct handling of script files, which do not need to specify a
> #library when using other library tags such as #import, #source or #resource.

If we injected #library, wouldn't that still mean that in browsers, using
#resource in a script is not being tested. It seems like for these kinds of
tests (and our #import, #source tests), you'd want the actual test to run as its
own iframe and observe the result from the controller frame. I think that's the
only way to faithfully duplicate the standalone test environment. Other ideas
include injecting the test framework code into the Dart script, but then main()
becomes a bit tricky. I'm not sure if any of these would work, but it's
something we could investigate if we feel that there's high risk the script case
will be broken.

WDYT about this change? I definitely see the downside that it reduces coverage
for scripts, though it does add coverage of the library case, and it gives us
coverage in Dartium and other browsers. Good enough on balance for check in?

(Regardless we can continue the larger discussion with whesse@ of whether we can
improve the test framework to not do wrapping of the Dart script.)

[Ivan Posva, 2012-03-07 19:09:52]

On 2012/02/23 01:47:12, John Messerly wrote:
> On 2012/02/23 01:12:23, Ivan Posva wrote:
> >
>
https://chromiumcodereview.appspot.com/9448001/diff/1/tests/language/src/Reso...
> > File tests/language/src/ResourceTest.dart (right):
> > 
> >
>
https://chromiumcodereview.appspot.com/9448001/diff/1/tests/language/src/Reso...
> > tests/language/src/ResourceTest.dart:5: #library('ResourceTest');
> > It would be preferable if the test harness would not just expect #library
but
> > could add a #library if needed. Because as it stands now it is impossible to
> > test for correct handling of script files, which do not need to specify a
> > #library when using other library tags such as #import, #source or
#resource.
> 
> If we injected #library, wouldn't that still mean that in browsers, using
> #resource in a script is not being tested. It seems like for these kinds of
> tests (and our #import, #source tests), you'd want the actual test to run as
its
> own iframe and observe the result from the controller frame. I think that's
the
> only way to faithfully duplicate the standalone test environment. Other ideas
> include injecting the test framework code into the Dart script, but then
main()
> becomes a bit tricky. I'm not sure if any of these would work, but it's
> something we could investigate if we feel that there's high risk the script
case
> will be broken.
> 
> WDYT about this change? I definitely see the downside that it reduces coverage
> for scripts, though it does add coverage of the library case, and it gives us
> coverage in Dartium and other browsers. Good enough on balance for check in?
> 
> (Regardless we can continue the larger discussion with whesse@ of whether we
can
> improve the test framework to not do wrapping of the Dart script.)

Please figure out how we can avoid the #library in scripts by adjusting the
harness or the test framework, but that should not have been blocking this
change.

-Ivan