Just a small precision because few people mentioned losing history. Even if the tests are moved the history is not gonna be lost it will just be a bit more difficult to follow.
Best, Stamatis On Fri, Feb 20, 2026 at 9:42 AM jensen <[email protected]> wrote: > > I agree to freeze > "RelOptRulesTest". My suggestion is to avoid migrating the tests here either > step by step or all at once, as that could result in losing important Git > information. This is because we might need to know who originally added a > particular test case. > > > > Best regards, > > Zhen Chen > > ---- Replied Message ---- > | From | Ruben Q L<[email protected]> | > | Date | 02/20/2026 16:26 | > | To | [email protected] | > | Cc | | > | Subject | Re: [DISCUSS] Stop testing rules inside RelOptRulesTest | > I think this is a good idea. > > I agree with Stamatis proposal of "freezing" RelOptRuleTest and from now on > adding new rule tests in separate, dedicated files. > Perhaps when adding a new test for rule X (in its dedicated file), the PR > contributor could examine RelOptRuleTest, see if there are existing tests > in there for said rule X, and "migrate" them into the new file (so that we > make RelOptRuleTest lighter little by little). > > Best, > Ruben > > > > On Fri, Feb 20, 2026 at 8:10 AM Stamatis Zampetakis <[email protected]> > wrote: > > > I don't intend to split the existing RelOptRuleTest class as this would be > > quite a bit of work with a few shortcomings as well. > > > > The proposal here is just for new tests. The majority of the tests are > > aiming a single rule/transformation so going forward we can have a separate > > class for the rule under test and put new cases there. > > > > I am currently working on a new rule so the respective PR may serve as an > > example to demonstrate concretely the idea. I will share it here once I > > finish it. > > > > Best, > > Stamatis > > > > On Fri, Feb 20, 2026, 8:37 AM Cancai Cai <[email protected]> wrote: > > > > > I agree with splitting the tests, but the question is how we should split > > > them, which is perhaps the most important point to discuss. > > > > > > Best wishes, > > > Cancai Cai > > > > > > > 2026年2月20日 07:25，Mihai Budiu <[email protected]> 写道： > > > > > > > > Sure, big files are annoying. > > > > > > > > Mihai > > > > > > > > From: Stamatis Zampetakis <[email protected]> > > > > Sent: Thursday, February 19, 2026 5:53 AM > > > > To: [email protected] <[email protected]> > > > > Subject: [DISCUSS] Stop testing rules inside RelOptRulesTest > > > > > > > > Hi all, > > > > > > > > The RelOptRulesTest.java has 12K lines of code and the respective > > > > RelOptRulesTest.xml file has 22K. Wherever we want to add tests for a > > > > specific rule we tend to put it there so inevitably these files are > > > > getting bigger and bigger, navigation becomes harder, conflicts > > > > increase, naming becomes challenging, etc. > > > > > > > > From now onwards we could adopt another pattern where the tests for > > > > each new rule (e.g., AggregateFilterMagicRule.java) reside into their > > > > own dedicated testing class (AggregateFilterMagicRuleTest.java) and > > > > XML file (AggregateFilterMagicRuleTest.xml). In other words, we stop > > > > adding tests in RelOptRulesTest.java at least for new rules. Thanks to > > > > the presence of the RelOptFixture class separating tests into > > > > dedicated classes is trivial and boilerplate code that is required for > > > > setting it up (e.g., DiffRepo) is rather minimal. > > > > > > > > Let me know your thoughts. > > > > > > > > Best, > > > > Stamatis > > > > > > > >
