Hi David, The files can be found here: https://github.com/apache/calcite/blob/a44373782fc4609f5da81a3c24725fd1af34ae8d/core/src/test/java/org/apache/calcite/test/RelOptRulesTest.java https://github.com/apache/calcite/blob/a44373782fc4609f5da81a3c24725fd1af34ae8d/core/src/test/resources/org/apache/calcite/test/RelOptRulesTest.xml
AggregateFilterMagicRule is just a fictional name that I invented for the example. Best, Stamatis On Thu, Feb 19, 2026 at 3:10 PM David Radley <[email protected]> wrote: > > Hi, > I have looked in master and cannot find this file. Where are you seeing it? > Kind regards, David. > > From: Stamatis Zampetakis <[email protected]> > Date: Thursday, 19 February 2026 at 13:54 > To: [email protected] <[email protected]> > Subject: [EXTERNAL] [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 > > Unless otherwise stated above: > > IBM United Kingdom Limited > Registered in England and Wales with number 741598 > Registered office: Building C, IBM Hursley Office, Hursley Park Road, > Winchester, Hampshire SO21 2JN
