Test Strategy for Cassandra

[manish khandelwal <ma...@gmail.com>]

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

Re: Test Strategy for Cassandra

[manish khandelwal <ma...@gmail.com>]

Thanks Josh for your insights. That distinction between unit tests and
dtests—especially in relation to intra-node vs. multi-node behavior—really
helps clarify things. I’ll take another look at the patch and work on
writing appropriate test cases accordingly, potentially shifting towards an
in-jvm dtest as you suggested.

Regarding the PR access: do I need to take any additional steps to make it
accessible? I had marked it as a draft PR since the test cases were still
pending, so perhaps that’s affecting visibility.

Thanks again for the guidance.

Best Regards
Manish

On Tue, May 13, 2025 at 4:05 PM Josh McKenzie <jm...@apache.org> wrote:

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

Re: Test Strategy for Cassandra

[Josh McKenzie <jm...@apache.org>]

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