I think the better way is to let test cases run under some conditions. for example, pl/python is optional, if user did not run configure with pl/python option, the test about pl/python should not run.
Cheers Lei On Tue, Jul 12, 2016 at 2:15 PM, Ivan Weng <[email protected]> wrote: > Agree with Hong. Test case should check its environment needed. If the > check failed, it should terminate the execution and report the error. > > On Tue, Jul 12, 2016 at 2:04 PM, Hong Wu <[email protected]> wrote: > > > It is user/developer themselves that should take care. Say, if you write > a > > test case which is related to plpython, why don't you configure HAWQ with > > "--with-python" option? We should write a README for feature-test that > > guides user to run this tests. For example, tell them sourcing > > "greenplum.sh" before running tests. > > > > Consequently, I think add such sanity-check is a little bit of > > over-engineering which will bring extra problems and complexities. > > > > Best > > xunzhang > > > > 2016-07-12 13:47 GMT+08:00 Paul Guo <[email protected]>: > > > > > I have >1 times to encounter some feature test failures due to reported > > > missing stuffs. > > > > > > e.g. > > > > > > 1. I did not have pl/python installed in my hawq build so > > > UDF/sql/function_set_returning.sql fails to "create language > > plpythonu" > > > This makes this case fails. > > > > > > 2. Sometimes I forgot to source a greenplum.sh, then all cases run > > > with failures due to missing psql. > > > > > > We seem to be able to improve. > > > > > > 1) Sanity-check some file existence in common code, e.g. > > > psql, gpdiff.pl, > > > > > > 2) Some cases could do sanity-check in their own test constructor > > > functions, > > > e.g. if the case uses the extension plpython, the test case should > > > check it itself. > > > > > > More thoughts? > > > > > >
