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