On Mon, 05/05 17:32, Kevin Wolf wrote: > Am 05.05.2014 um 17:21 hat Stefan Hajnoczi geschrieben: > > On Wed, Apr 30, 2014 at 10:55:07AM -0400, Jeff Cody wrote: > > > This adds some common functionality to control QEMU for qemu-iotests. > > > > > > Additionally, test 085 is updated to use this new functionality. > > > > > > Some minor fixups along the way, to clear up spaced pathname issues, > > > for common.rc, test 019, and test 086. > > > > > > > > > Jeff Cody (3): > > > block: qemu-iotests - add common.qemu, for bash-controlled qemu tests > > > > Once a test launches QEMU, it soon needs to parse QMP commands or wait > > for QMP events. That doesn't lend itself to the traditional > > qemu-iotests shell model. That is why iotests.py exists. > > > > Shell script is a poor language for test cases that go beyond > > pre-defined commands whose output is saved for diffing. The string > > manipulation is clumsy, JSON is not supported, tricks with fifos can > > easily deadlock or break when a process terminates unexpectedly, etc. > > > > If we go further in the direction of this patch series, we'll duplicate > > existing iotests.py code and have complex shell tests that are hard to > > extend. I think it's time to draw the line and convert any test cases > > that need to complexity to Python. > > > > Why not use iotests.py? > > Because it's hard to use. The "compare against reference output" thing > is the first thing that you lose with iotests.py, and it's the most > useful feature in qemu-iotests. > > When a Python test case fails, you get into real debugging. When a shell > script test case fails, you usually see immediately from the reference > output diff what's wrong. >
Perhaps we should add more error information into iotests.py, if a test case fails. Otherwise I don't think iotests.py hard to use though, out of my subjective point. I agree that shell is not as goog as python in this kind of test. Fam
