jtreg shell tests

Andrew Luo andrewluotechnologies at outlook.com
Sat Jan 26 01:05:32 UTC 2019


Isn't that option 1?

Thanks,

-Andrew

-----Original Message-----
From: quality-discuss <quality-discuss-bounces at openjdk.java.net> On Behalf Of Sergey Bylokhov
Sent: Friday, January 25, 2019 5:00 PM
To: Jonathan Gibbons <jonathan.gibbons at oracle.com>; quality-discuss at openjdk.java.net
Subject: Re: jtreg shell tests

There is one more Option 5.

Drop shell tests from the workspace and provide some examples on how to write such logic using java api.

On 25/01/2019 16:43, Jonathan Gibbons wrote:
> With all the recent discussion regarding how to support the use of 
> Windows Subsystem for Linux (WSL) as an alternate to Cygwin, it seems worth writing up some recommendations on writing jtreg shell tests.
> The intent of these notes is that they will evolve into a page in the jtreg section on the OpenJDK website.
> 
> The focus is specifically about different approaches to providing the 
> ability to run a shell test on all supported platforms, by means of 
> abstracting the significant differences into a series of environment variables that are set according to the environment in which the test is running.
> 
> Option 1.
> 
> Convert the test to Java. In general, this continues to be the recommended alternative.
> 
> 
> Option 2.
> 
> Use a shell `case` statement, like the following, or a variant thereof:
> 
>     OS=`uname -s`;
>     case "$OS" in
>          Windows* | CYGWIN* )
>              FS="\\"
>              PS=";"
>              NULL=NUL
>              ;;
> 
>          Linux )
>              if [ -r $TESTJAVA/bin/java.exe ]; then
>                  FS="\\"
>                  PS=";"
>                  EXE_SUFFIX=".exe"
>              else
>                  FS="/"
>                  PS=":"
>              fi
>              NULL=/dev/null
>              ;;
> 
>          * )
>              FS="/"
>              PS=":"
>              NULL=/dev/null
>     esac
> 
> Option 3.
> 
> Use a shared library script to embody the behavior in the previous example.  jtreg now provides a new `TESTROOT` environment variable, which makes it easy to reference a shared script in a constant manner from any shell test, wherever the test is within the test suite. Since the library script is used to set environment variables like `FS`, `PS`, and `NULL`, it should be executed with `source` and not `bash` or `sh`.
> 
> 
> Option 4.
> 
> jtreg now sets the following environment variables when running a shell script: `FS`, `PS`, `NULL` and `EXE_SUFFIX`.  This may be enough to completely avoid the need for a `case` statement in each shell script or the use of a shared library script to set these variables.
> 
> 
> Running scripts standalone.
> 
> One concern when working with shell tests has been the ability to run the test "stand-alone", without the use of jtreg. In the past, this was seen as justification for the explicit use of the `case` statement in each shell test. However, the need to run shell tests standalone no longer seems to be a significant concern. For those that do want to run shell tests by themselves, it is worth noting that once a test has been run by jtreg, the ".jtr" file contains "rerun" sections with details on how to run each action of the test. You can either copy/paste/edit from the ".jtr" file directly, or use the jtreg `-show:rerun` option to output the information to the standard output stream.
> 
> 
> 


--
Best regards, Sergey.


More information about the quality-discuss mailing list