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 > > > > >
