+1 Sounds like a great change that will help us unify around a common testing paradigm, and even pave the path to in-tree load testing plus integrated correctness checking which would be extremely valuable!
-Joey On Thu, Dec 21, 2023 at 1:35 PM Caleb Rackliffe <calebrackli...@gmail.com> wrote: > +1 > > Agree w/ all the justifications mentioned above. > > As a reviewer on CASSANDRA-19210 > <https://issues.apache.org/jira/browse/CASSANDRA-19210>, my goals were to > a.) look at the directory, naming, and package structure of the ported > code, b.) make sure IDE integration was working, and c.) make sure any > modifications to existing code (rather than direct code movements from > cassandra-harry) were straightforward. > > On Thu, Dec 21, 2023 at 3:23 PM Alex Petrov <al...@coffeenco.de> wrote: > >> Hey folks, >> >> I am mostly done with a patch that brings Harry in-tree [1]. I will >> trigger one more CI run overnight, and my intention was to merge it some >> time soon, but I wanted to give a fair warning here, since this is a >> relatively large patch. >> >> Good news for everyone that it: >> a) touches no production code whatsoever. Only test (in-jvm dtest >> namely) code that was using Harry already. >> b) the only tests that are changed are ones that used a duplicate >> version of placement simulator we had both for testing TCM, and in Harry >> c) in addition, I have converted 3 existing TCM tests to a new API to >> have some base for examples/usage. >> >> Since we were effectively relying on this code for a while now, and the >> intention now is to converge to: >> a) fewer different generators, and have a shareable version of >> generators for everyone to use accross the base >> b) a testing tool that can be useful for both trivial cases, and >> complex scenarios >> myself and many other Cassandra contributors have expressed an opinion >> that bringing Harry in-tree will be highly benefitial. >> >> I strongly believe that bringing Harry in-tree will help to lower the >> barrier for fuzz test and simplify co-development of Cassandra and Harry. >> Previously, it has been rather difficult to debug edge cases because I had >> to either re-compile an in-jvm dtest jar and bring it to Harry, or >> re-compile a Harry jar and bring it to Cassandra, which is both tedious and >> time consuming. Moreover, I believe we have missed at very least one RT >> regression [2] because Harry was not in-tree, as its tests would've caught >> the issue even with the model that existed. >> >> For other recently found issues, I think having Harry in-tree would have >> substantially lowered a turnaround time, and allowed me to share repros >> with developers of corresponding features much quicker. >> >> I do expect a slight learning curve for Harry, but my intention is to >> build a web of simple tests (worked on some of them yesterday after >> conversation with David already), which can follow the in-jvm-dtest pattern >> of find-similar-test / copy / modify. There's already copious >> documentation, so I do not believe not having docs for Harry was ever an >> issue, since there have been plenty. >> >> You all are aware of my dedication to testing and quality of Apache >> Cassandra, and I hope you also see the benefits of having a model checker >> in-tree. >> >> Thank you and happy upcoming holidays, >> --Alex >> >> [1] https://issues.apache.org/jira/browse/CASSANDRA-19210 >> [2] https://issues.apache.org/jira/browse/CASSANDRA-18932 >> >>
