From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 4F1F91FF0E0 for ; Thu, 23 Jul 2026 11:28:58 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id A4123214CA; Thu, 23 Jul 2026 11:28:57 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 23 Jul 2026 11:28:52 +0200 Message-Id: To: "Elias Huhsovitz" , Subject: Re: [PATCH access-control 2/2] test: api: add tests for ACL modification endpoint From: "Daniel Kral" X-Mailer: aerc 0.21.0-147-g43ac7b685014-dirty References: <20260720134535.136172-1-e.huhsovitz@proxmox.com> <20260720134535.136172-3-e.huhsovitz@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784798903360 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.222 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: UL3WDJCZX4UI3MEBJXU76FKKTYC4QVTV X-Message-ID-Hash: UL3WDJCZX4UI3MEBJXU76FKKTYC4QVTV X-MailFrom: d.kral@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu Jul 23, 2026 at 11:00 AM CEST, Elias Huhsovitz wrote: >>> +} >>> + >>> +sub run_update_acl ($params) { >>> + my $result =3D 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 =3D> { ... }, >> # can be made empty for specific test cases, etc. >> permissions =3D> { 'Permissions.Modify' =3D> 1 }, >> expected_acl_root =3D> { ... }, >> } >> >> 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=20 > - 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=20 > 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.