[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-5.0 v2 18/23] iotests: Add VM.assert_block_path()
From: |
Max Reitz |
Subject: |
Re: [PATCH for-5.0 v2 18/23] iotests: Add VM.assert_block_path() |
Date: |
Mon, 9 Dec 2019 16:10:41 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 |
On 03.12.19 13:59, Vladimir Sementsov-Ogievskiy wrote:
> 11.11.2019 19:02, Max Reitz wrote:
>> Signed-off-by: Max Reitz <address@hidden>
>> ---
>> tests/qemu-iotests/iotests.py | 59 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 59 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
>> index d34305ce69..3e03320ce3 100644
>> --- a/tests/qemu-iotests/iotests.py
>> +++ b/tests/qemu-iotests/iotests.py
>> @@ -681,6 +681,65 @@ class VM(qtest.QEMUQtestMachine):
>>
>> return fields.items() <= ret.items()
>>
>> + """
>> + Check whether the node under the given path in the block graph is
>> + @expected_node.
>> +
>> + @root is the node name of the node where the @path is rooted.
>> +
>> + @path is a string that consists of child names separated by
>> + slashes. It must begin with a slash.
>
> Why do you need this slash?
I don’t. It just looked better to me.
(One reason would be so it could be empty to refer to @root, but as I
said that isn’t very useful.)
> To stress that we are starting from root?
> But root is not global, it's selected by previous argument, so for me the
> path is more like relative than absolute..
>
>> +
>> + Examples for @root + @path:
>> + - root="qcow2-node", path="/backing/file"
>> + - root="quorum-node", path="/children.2/file"
>> +
>> + Hypothetically, @path could be empty, in which case it would point
>> + to @root. However, in practice this case is not useful and hence
>> + not allowed.
>
> 1. path can't be empty, as accordingly to previous point, it must start with
> '/'
Hence “hypothetically”.
> 2. path can be '/', which does exactly what you don't allow, and I don't see,
> where it is restricted in code
No, it doesn’t. That refers to a child of @root with an empty name.
>> +
>> + @expected_node may be None.
>
> Which means that, we assert existence of the path except its last element,
> yes? Worth mention this behavior here.
“(All elements of the path but the leaf must still exist.)”? OK.
>> +
>> + @graph may be None or the result of an x-debug-query-block-graph
>> + call that has already been performed.
>> + """
>> + def assert_block_path(self, root, path, expected_node, graph=None):
>> + if graph is None:
>> + graph = self.qmp('x-debug-query-block-graph')['return']
>> +
>> + iter_path = iter(path.split('/'))
>> +
>> + # Must start with a /
>> + assert next(iter_path) == ''
>> +
>> + node = next((node for node in graph['nodes'] if node['name'] ==
>> root),
>> + None)
>> +
>> + for path_node in iter_path:
>> + assert node is not None, 'Cannot follow path %s' % path
>> +
>> + try:
>> + node_id = next(edge['child'] for edge in graph['edges'] \
>> + if edge['parent'] ==
>> node['id'] and
>> + edge['name'] == path_node)
>> +
>> + node = next(node for node in graph['nodes'] \
>> + if node['id'] == node_id)
>
> this line cant fail. If it fail, it means a bug in x-debug-query-block-graph,
> so,
> I'd prefer to move it out of try:except block.
But that makes the code uglier, in my opinion. We’d then have to set
node_id to e.g. None in the except branch (or rather just abolish the
try-except then) and check whether it’s None before assigning node.
Like this:
node_id = next(..., None)
if node_id is not None:
node = next(...)
else:
node = None
I prefer the current try-except construct over that.
>> + except StopIteration:
>> + node = None
>> +
>> + assert node is not None or expected_node is None, \
>> + 'No node found under %s (but expected %s)' % \
>> + (path, expected_node)
>> +
>> + assert expected_node is not None or node is None, \
>> + 'Found node %s under %s (but expected none)' % \
>> + (node['name'], path)
>> +
>> + if node is not None and expected_node is not None:
>
> [1]
> second part of condition already asserted by previous assertion
Yes, but I wanted to cover all four cases explicitly. (In the usual 00,
01, 10, 11 manner. Well, except it’s 10, 01, 11, 00.)
>> + assert node['name'] == expected_node, \
>> + 'Found node %s under %s (but expected %s)' % \
>> + (node['name'], path, expected_node)
>
> IMHO, it would be easier to read like:
>
> if node is None:
> assert expected_node is None, \
> 'No node found under %s (but expected %s)' % \
> (path, expected_node)
> else:
> assert expected_node is not None, \
> 'Found node %s under %s (but expected none)' % \
> (node['name'], path)
>
> assert node['name'] == expected_node, \
> 'Found node %s under %s (but expected %s)' % \
> (node['name'], path, expected_node)
>
> Or even just
>
> if node is None:
> assert expected_node is None, \
> 'No node found under %s (but expected %s)' % \
> (path, expected_node)
> else:
> assert node['name'] == expected_node, \
> 'Found node %s under %s (but expected %s)' % \
> (node['name'], path, expected_node)
Works for me, too.
> (I've checked:
> >>> 'erger %s erg' % None
> 'erger None erg'
>
> Also, %-style formatting is old, as I understand it's better always use
> .format()
> )
OK.
Max
>>
>> index_re = re.compile(r'([^\[]+)\[([^\]]+)\]')
>>
>>
signature.asc
Description: OpenPGP digital signature