Given the title on 20291: "Batch queries timeout when private IP of a node fails in multi-dc Cassandra setup", this seems like a prime candidate for an in-jvm dtest. The way I think about it: if I need to exercise intra-node communication or functionality to confirm that something operates the way I think it does, dtest it is. If whatever I'm testing has functionality purely encapsulated by the operations of a single node (changes to storage formats, in-memory representation, etc), then a unit test is fine.
More often nowadays it ends up being a combination of: 1. property-testing on a class(es) 2. integration testing on the node level (our historical "unit" test) 3. then an in-jvm dtest to confirm multi-node operations, especially in the presence of mixed version clusters (i.e. during upgrades) or mixed-configuration features (i.e. rolling restart flipping flag to enable a feature). I can't seem to access the PR on 20291 to give more insight or confirm, but hopefully the above heuristic proves helpful. On Tue, May 13, 2025, at 3:38 AM, manish khandelwal wrote: > Hi everyone > > I have a question regarding test strategy in Cassandra. Under what > circumstances is a dtest preferred over a unit test? Specifically, what > criteria should guide the decision to write a dtest instead of a unit test? > I’ve prepared a patch for *CASSANDRA-20291*, but I’m encountering some > challenges in writing unit tests—primarily due to the limited support for > mocking in the Cassandra codebase. As a result, I’m considering shifting > towards dtests and would appreciate any guidance on this. > Regards > Manish
