Bug 68511

Summary: [EFL] Script for running WebKit-EFL Unit Tests
Product: WebKit Reporter: Krzysztof Czech <k.czech>
Component: WebKit EFLAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Enhancement CC: gyuyoung.kim, gyuyoung.kim, lucas.de.marchi, rakuco, tmpsantos
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: Linux   
Bug Depends on:    
Bug Blocks: 86092    
Attachments:
Description Flags
Patch
leandro: review-
Patch none

Description Krzysztof Czech 2011-09-21 01:52:56 PDT
Support for running unit tests automatically.
Comment 1 Krzysztof Czech 2011-09-21 01:54:30 PDT
Created attachment 108124 [details]
Patch
Comment 2 Gyuyoung Kim 2011-09-21 02:01:34 PDT
I think it is better to notify this contribution to webkit-dev mailing list first.
Comment 3 Leandro Pereira 2011-09-21 10:53:56 PDT
Comment on attachment 108124 [details]
Patch

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

Informal r- for the reasons below.

> Tools/Scripts/run-efl-tests:52
> +sub runTest
> +{
> +    my $args = @_[0];
> +    my $pathToBinary = "Source/Programs/EUnitTests";
> +    my $utName = "";
> +    if (length($args) > 0) {
> +        $utName = " --gtest_filter=" . $args . ".*" . "\n";
> +    }
> +    exit system($pathToBinary . $utName);

My Perl-fu is a bit rusty, but wouldn't the following be more readable and less prone to escaping problems?

sub runTest { 
  my ($testFilter) = @_;
  my $pathToTestUtility = 'Source/Programs/EUnitTests';
  my @testArgs = ($pathToTestUtility);

  push @testArgs, ('--gtest_filter', "${testFilter}.*\n") if $testFilter;  
  return system(@testArgs);
}

> Tools/Scripts/run-efl-tests:57
> +sub usage
> +{
> +    my $programName = basename($0);

Even though this is fine, the common pattern in WebKitPerl is to declare subroutine parameters as such (notice the more descriptive name as well):

sub printUsage
{
   my ($programName) = @_;
   ...
}

> Tools/Scripts/run-efl-tests:64
> +    print STDERR $usageText;

Why is this printed to STDERR?

> Tools/Scripts/run-efl-tests:65
> +    exit 1;

Why does the program return 1 when successfully printing the help output?
Comment 4 Krzysztof Czech 2011-09-22 01:01:14 PDT
(In reply to comment #3)
> (From update of attachment 108124 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=108124&action=review
> 
> Informal r- for the reasons below.
> 
> > Tools/Scripts/run-efl-tests:52
> > +sub runTest
> > +{
> > +    my $args = @_[0];
> > +    my $pathToBinary = "Source/Programs/EUnitTests";
> > +    my $utName = "";
> > +    if (length($args) > 0) {
> > +        $utName = " --gtest_filter=" . $args . ".*" . "\n";
> > +    }
> > +    exit system($pathToBinary . $utName);
> 
> My Perl-fu is a bit rusty, but wouldn't the following be more readable and less prone to escaping problems?
> 
> sub runTest { 
>   my ($testFilter) = @_;
>   my $pathToTestUtility = 'Source/Programs/EUnitTests';
>   my @testArgs = ($pathToTestUtility);
> 
>   push @testArgs, ('--gtest_filter', "${testFilter}.*\n") if $testFilter;  
>   return system(@testArgs);
> }
> 
Your suggestion is good, I'm bit new to the perl so your Perl-fu is better than mine
> > Tools/Scripts/run-efl-tests:57
> > +sub usage
> > +{
> > +    my $programName = basename($0);
> 
> Even though this is fine, the common pattern in WebKitPerl is to declare subroutine parameters as such (notice the more descriptive name as well):
> 
> sub printUsage
> {
>    my ($programName) = @_;
>    ...
> }
> 
> > Tools/Scripts/run-efl-tests:64
> > +    print STDERR $usageText;
> 
> Why is this printed to STDERR?
Allows stream redirection. "Help" in this context informs the user, that something did wrong.
> 
> > Tools/Scripts/run-efl-tests:65
> > +    exit 1;
> 
> Why does the program return 1 when successfully printing the help output?
Point at, this is a failure situation
Comment 5 Krzysztof Czech 2011-09-26 07:49:00 PDT
Created attachment 108666 [details]
Patch
Comment 6 Leandro Pereira 2011-10-19 09:31:49 PDT
Comment on attachment 108666 [details]
Patch

LGTM.
Comment 7 Raphael Kubo da Costa (:rakuco) 2012-01-01 17:20:24 PST
Coming to think of it again, I wonder if this script is really needed. Wouldn't using CMake's infrastructure for tests be enough (ie. running `make test' then runs the unit tests)?
Comment 8 Krzysztof Czech 2012-01-02 03:19:19 PST
I also thought about it. On the other hand, there are already available similar scripts for other ports: run-gtk-tests, run-chromium-webkit-unit-tests, run-api-tests. I'am not sure if this is some kind of convention of adding this kind of scripts. Apart from this we could also use CMake infrastructure.
Comment 9 Gyuyoung Kim 2012-01-02 20:29:28 PST
If there is a script for running EFL test, I'm please with it. But, it looks this patch can't be landed until other patches are landed. In addition, I think you need to notify this patch to webkit-dev. I think you have to get agreement from webkit community or reviewers.
Comment 10 Thiago Marcos P. Santos 2012-06-28 06:47:50 PDT
I'm not sure if this makes sense anymore. I think it can be done by using CTest and a build target. We don't have a global runner anymore. See bug 87251.
Comment 11 Thiago Marcos P. Santos 2012-07-02 11:28:52 PDT
(In reply to comment #10)
> I'm not sure if this makes sense anymore. I think it can be done by using CTest and a build target. We don't have a global runner anymore. See bug 87251.

Should we close this bug?
Comment 12 Thiago Marcos P. Santos 2012-07-03 09:21:57 PDT

*** This bug has been marked as a duplicate of bug 87251 ***
Comment 13 Raphael Kubo da Costa (:rakuco) 2012-07-03 21:09:30 PDT
Comment on attachment 108666 [details]
Patch

Clearing r? flag from the patch.