[
https://issues.apache.org/jira/browse/BIGTOP-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488225#comment-13488225
]
Wing Yew Poon commented on BIGTOP-769:
--------------------------------------
Johnny, this proposal is simply to offer an easy to use way of executing shell
script based tests, much like HiveBulkScriptExecutor is a tool for executing
hive query scripts, and TestHiveSmokeBulk is a JUnit parameterized test
(written in groovy) that uses HiveBulkScriptExecutor to actually execute the
tests.
So, in order to execute the tests within the iTest framework, you'd still write
a (parameterized) JUnit test (in groovy or java), using the shell script
executor. On the other hand, the shell scripts themselves could be written in
such a way that they could be run directly in a shell (i.e., outside of iTest
and maven), after setting the necessary variables. So the intent is to make
both ways of execution possible.
Not all tests fit into this paradigm. However, if a test consists mostly or
entirely of Shell#exec() calls and asserts, then they are good candidates for
being written as straight shell scripts and executed using this executor. Once
more complex logic enters the test, you might not want to write the logic in
bash anymore but in java or groovy, and if you need to make use of hadoop/hbase
api and so forth, then definitely they are not good candidates for shell script
based tests.
> Create a generic shell executor iTest driver
> --------------------------------------------
>
> Key: BIGTOP-769
> URL: https://issues.apache.org/jira/browse/BIGTOP-769
> Project: Bigtop
> Issue Type: Improvement
> Components: Tests
> Affects Versions: 0.4.0
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Fix For: 0.5.0
>
>
> It would be nice to have a way of generically wrapping up shell-based tests
> in iTest framework.
> I imagine a pretty simple implementation (at least initially) where on the
> iTest side we'd have a parameterized testsuite that would look inside a
> specific location under resources and instantiate one test per shell script
> that it finds there (subject to include/exclude filtering constraints). Then
> the tests will be exec'ed inside of a pre-set UNIX environment one-by-one (no
> parallel execution for now). If shell returns 0 -- the test passes, non 0 --
> fails (and the stderr/stdout get captured).
> Finally, I don't have any better answer to what the contract for the
> environment should be, but I'd like folks to chime in with suggestions. We
> can probably start with populating it with ALL of the properties extracted
> from Hadoop config files (core-site.xml, hdfs-site.xml, etc.) with obvious
> transformations (fs.default.name becomes FS_DEFAULT_NAME, etc.). Or we can
> have a manifest of what's allowed and what tests can rely on.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
