Re: [PATCH access-control 2/2] test: api: add tests for ACL modification endpoint

["Daniel Kral" <d.kral@proxmox.com>]

On Thu Jul 23, 2026 at 11:00 AM CEST, Elias Huhsovitz wrote:
>>> +}
>>> +
>>> +sub run_update_acl ($params) {
>>> +    my $result = eval { $handler->handle($handler_info, $params) };
>>> +    return ($result, $@);
>>> +}
>>
>> Hm, I wonder whether the test cases would be a little more compact and
>> reviewable by following the usual test case structure which is
>>
>> - defining an array full of hashes where each hash represents a test
>>   case
>> - a loop then goes through each test case
>>
>> Each test case could then make a deep comparison between the resulting
>> $current_cfg->{acl_root}, which is reset for each test case entry.
>>
>> As a proposal for a possible test case entry could be:
>>
>>     {
>>         update_acl_params => { ... },
>>         # can be made empty for specific test cases, etc.
>>         permissions => { 'Permissions.Modify' => 1 },
>>         expected_acl_root => { ... },
>>     }
>>
>> What do you think?
>
> I also like this kind of style.
>
> I used the following guide as a base: https://perlmaven.com/testing
> and it mentioned the subtest keyword here: https://perlmaven.com/subtest
>
> There subtest keyword is also used in some other repositories, such as 
> - pve-container/src/test/snapshot-test.pm
> - qemu-server/src/test/snapshot-test.pm
> - pve-container/src/test/idmap-test.pm
>
> So i was not sure what the preferred approach currently is.
>
> I did it this way, since I am more familiar with JUnit5 as a testing 
> framework. I don't view the additional verbosity as a bad thing in
> this case, since it provides a bit more description and makes it easier
> to modify existing tests in the future.
>
> I appreciate the simplicity of the approach you suggested
> and can implement this style in v2.

Your style is fine as it is, so no hard feelings here ;)

It was just a suggestion because the test cases do similar things it's
nice to factor them so there's less repetition to call before_each() in
each subtest and have similar is() and ok() tests.

If we want to add test cases which test other stuff then it's fine to
add either another test script or another subroutine which handles
another @array full of test cases.