On 05/29/2012 04:54 AM, guyanhua wrote: > at 5/25/2012 9:35 PM, Chris Evich wrote: >> On 05/24/2012 10:41 PM, guyanhua wrote: >> Here, I think you can re-use the virsh_cmd() function instead of >> utils.run(), no? > > Here,I think we can not re-use the virsh_cmd() function instead of > utils.run(). > First, in virsh_cmd() function, it uses the default > param(ignore_status=False) of utils.run(), > it means that if we give a wrong param of command, it will get a > status(!=0) , raise error > and interrupt the test. Contrary, our aim is to test whether the command > is right. > when it gets a wrong param of command, the status shouldn't be equal to > zero, which we hope. > And we also hope it keeps running normally. > Second, in virsh_cmd() function, it only returns the output of the > command, no exit status. But in > our tests we will use the status for further check. >
Yes, all good points and to what Alex said too, let's just make virsh_cmd() better to meet your requirements. I fully agree, as implemented currently it's very inflexible/limited, especially for error testing. FYI, here is copy of response I sent to tangchen on same topic. Maybe this idea would work for you too? On 05/29/2012 10:30 AM, Chris Evich wrote: >> On 05/28/2012 03:04 AM, tangchen wrote: >> The problem here is that users cannot judge if the virsh command runs >> correctly through stdout returned by virsh_cmd(). So we make >> virsh_cmd() raise an exception when the command is wrong. >> >> My idea was catching and handling exception in virsh_cmd(), and >> making virsh_cmd() return two values: command's exit status and >> stdout. In this way, users don't need to handle exceptions, and they >> are able to know the command is wrong with exit status. >> >> But if we do so, wherever virsh_cmd() is called should be modified. >> It will be a large number of work. I am still thinking about it. >> There may be something coincident with your idea. :) >> > > Yes, changing the behavior too much will break a lot of stuff (I did it > before :) What about adding an optional keyword parameter like > 'extended_return=False'? When set 'True' make it return cmd_result > instance. Or, if we want to shell users away from dealing with > cmd_result, return a tuple instead, like '(stdout,stderr,exitcode)'. I > think this could be a good compromise. > -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
