Skip to content

Conversation

@mattias-p
Copy link
Member

@mattias-p mattias-p commented Nov 23, 2023

Purpose

This PR implements flexible command line overriding of which test cases to run from the command line.

Context

Changes

  • The set of values accepted by --test is extended.

  • Which test cases to include in the run is now controlled by setting the test_cases profile property and running Zonemaster::Engine->test_zone().

  • When --test=basic or --test=basic02 is specified, and basic02 considers the domain too broken to test, a CANNOT_CONTINUE message is now emitted, whereas it wasn't emitted before this PR.

Reviewing

  • Look especially for lacking test coverage.

Testing

  • Unit tests should pass.

@mattias-p mattias-p changed the base branch from master to develop November 23, 2023 08:16
@matsduf
Copy link
Contributor

matsduf commented Nov 23, 2023

  • Before this PR CLI would call either test_zone, test_module or test_method in Zonemaster::Engine
    to run the test. After this PR CLI always calls test_zone and uses the test_cases profile property to
    control which tests are run. This means that the Basic tests are always included even when a single test case
    is specified.

  • Since the semantics of specifying a single test case or single test module is changed so that the Basic tests
    are included, an argument could be made that this is a breaking change, but I believe an argument could also
    be made that it's still just an addition.

That is a bad change. When working with test zones you want to be able to run just the specific test case and nothing else.

Secondly, with that change, if Basic fails completely no other test case is run, and that is not what we want when testing and creating test zones.

I am against a change that makes it impossible to run just the selected test case.

@mattias-p
Copy link
Member Author

All I'm hearing is "no" and "bad". Is there anything about this proposal that you do like?

Also, I'm trying to understand your objection here. AFAICT you're saying that when a user requests that a single test case is run on a domain that doesn't fulfill the requirements posed by Basic, the requested test case still needs to run. Is that correct? And if so, could you explain why this is important, because it's not obvious to me.

@matsduf
Copy link
Contributor

matsduf commented Nov 23, 2023

All I'm hearing is "no" and "bad". Is there anything about this proposal that you do like?

It would be good to be able to exclude test cases without creating a new profile. It would be good to be able to select two or more test cases and they are run without overlap.

Sometimes it is probably good that Basic is run before a selected test.

Also, I'm trying to understand your objection here. AFAICT you're saying that when a user requests that a single test case is run on a domain that doesn't fulfill the requirements posed by Basic, the requested test case still needs to run. Is that correct? And if so, could you explain why this is important, because it's not obvious to me.

I want to see what happens in that test case for the test zone even when there are errors. And I want minimal output without the extra output from Basic when testing test zones. Sometimes I have to run with --level debug which gives many lines, which will be anymore if Basic is run.

Give the possibility to run a test without adding Basic.

If Basic is not in the profile, why should Basic still be run? The magic could rather be to put the Basic test cases in the profile first, if there are any.

@mattias-p
Copy link
Member Author

mattias-p commented Nov 23, 2023

I want to see what happens in that test case for the test zone even when there are errors. And I want minimal output without the extra output from Basic when testing test zones. Sometimes I have to run with --level debug which gives many lines, which will be anymore if Basic is run.

If Basic is not in the profile, why should Basic still be run? The magic could rather be to put the Basic test cases in the profile first, if there are any.

Ok. Yeah, I see how this could be very valuable in development contexts. And I also don't particularly like that Basic is forced.

I have an idea of how we could simplify things in Engine in a way that supports this. I think I'll make a draft PR there too.

I won't make any more updates to the code here before Engine is in a better shape to support it. But if anyone has more feedback on the direction of this PR, please let me know. Maybe it'll affect the updates in Engine.

@matsduf
Copy link
Contributor

matsduf commented Nov 11, 2024

@mattias-p, is this still relevant or can it be closed now?

@mattias-p mattias-p modified the milestones: v2024.2, v2025.1 Nov 11, 2024
@mattias-p
Copy link
Member Author

mattias-p commented Nov 11, 2024

This conflicts with #371 as well as some of its documentation improvement followups. I plan to rebase this PR once those things have been merged. It seems somewhat unreasonable to get this merged for 2024.2 so I postponed it.

@mattias-p mattias-p force-pushed the test-option branch 2 times, most recently from ecf71b3 to b316e12 Compare November 12, 2024 17:25
@matsduf matsduf modified the milestones: v2025.1, v2024.2 Nov 13, 2024
@mattias-p mattias-p force-pushed the test-option branch 2 times, most recently from 5ebbad5 to 7690a3c Compare November 14, 2024 14:02
@mattias-p mattias-p added the V-Major Versioning: The change gives an update of major in version. label Nov 14, 2024
@mattias-p mattias-p modified the milestones: v2025.1, v2024.2 Nov 14, 2024
@mattias-p mattias-p marked this pull request as ready for review November 14, 2024 15:15
@mattias-p
Copy link
Member Author

I rebased this onto latest develop and fixed some typos added some unit tests. I also tightened some validations for sanity reasons, but that shouldn't have any effect on zonemaster-cli behavior.

@mattias-p
Copy link
Member Author

Can you please give a more explicit description of the module? I still do not understand it.

I read through the module documentation again and I agree there was some room for improvement. So I worked through it again.

@mattias-p
Copy link
Member Author

I've rebased onto current develop and also improved the documentation.

Please review again.

Copy link
Contributor

@matsduf matsduf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fine, but I have some comments on the documentation to make is clearer. The functions work well.

@mattias-p
Copy link
Member Author

@matsduf, I applied your suggestions. Please review again.

matsduf
matsduf previously approved these changes Jun 5, 2025
Copy link
Contributor

@marc-vanderwal marc-vanderwal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine.

I’ve run the test suite through Devel::Cover and found a single line in TestCaseSet.pm that wasn’t covered by the test suite. Otherwise it’s 100% covered.

}
}
else {
croak "Unrecognized operator '$op'";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is the only thing not covered by the existing unit tests.

} ## end for my $case ( @cases )
}; ## end 'new' => sub

subtest 'apply_modifier' => sub {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be a test case checking whether there is a croak if passing an illegal modifier.

@mattias-p
Copy link
Member Author

I've rebased and added a unit test for invalid operators. The unit test is slightly messy, but I didn't know how to do it more cleanly. Please review again.

@mattias-p mattias-p merged commit 3973afb into zonemaster:develop Jun 10, 2025
3 checks passed
@marc-vanderwal
Copy link
Contributor

Successfully release tested on Rocky Linux 9.

Unit tests pass, and I did a few test runs with varying --test command line arguments, using the new expression syntax this PR introduces. It seems to work as intended.

@marc-vanderwal marc-vanderwal added the S-ReleaseTested Status: The PR has been successfully tested in release testing label Jun 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-ReleaseTested Status: The PR has been successfully tested in release testing V-Major Versioning: The change gives an update of major in version.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants