Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

My logic here was that CQLTester tests would probably be the best candidate as they are largely single-threaded and single-node. I'm sure there are background processes that might slow things down when serialised into a single execution thread, but my expectation would be that it will not be as

Re: Voice of Apache (Feathercast) at summit?

Rich, thank you for the kind offer! I'm happy to help find folks to participate - what day/time would you want to do this? Would it be a single interview, panel style, or a few different interviews with individuals? On Thu, Dec 7, 2023 at 3:29 PM Mick Semb Wever wrote: > > > On Tue, 5 Dec 2023 a

Re: Voice of Apache (Feathercast) at summit?

On Tue, 5 Dec 2023 at 15:35, Rich Bowen wrote: > Hey, folks. I'll be at Cassandra Summit next week, and was wondering if > any of you who might be there would be interested in doing a podcast > interview with me for Voice Of Apache (the podcast formerly known as > Feathercast - see https://feathe

[ANNOUNCE] Apache Cassandra Java Driver 4.18.0 test artifact available

The test build of Cassandra Java Driver 4.18.0 is available. sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9 Git: https://github.com/apache/cassandra-java-driver/tree/4.18.0 Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1322

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

I think the biggest impediment to that is that most tests are probably not sufficiently robust for simulation. If things happen in a surprising order many tests fail, as they implicitly rely on the normal timing of things.Another issue is that the simulator does potentially slow things down a littl

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

We have been extensively using simulator for TCM, and I think we have make simulator tests more approachable. I think many of the existing tests should be ran under simulator instead of CQLTester, for example. This will both strengthen the simulator, and make things better in terms of determinis

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

To be fair, the lack of coherent framework doesn’t mean we can’t merge them from a naming perspective. I don’t mind losing one of burn or fuzz, and merging them. Today simulator tests are kept under the simulator test tree but that primarily exists for the simulator itself and testing it. It’s

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

Yes, the only system/real-time timeout is a progress one, wherein if nothing happens for ten minutes we assume the simulation has locked up. Hitting this is indicative of a bug, and the timeout is so long that no realistic system variability could trigger it. > On 7 Dec 2023, at 14:56, Brandon

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

On Thu, Dec 7, 2023 at 8:50 AM Alex Petrov wrote: > > I've noticed many "sleeps" in the tests - is it possible with simulation > > tests to artificially move the clock forward by, say, 5 seconds instead of > > sleeping just to test, for example whether TTL works?) > > Yes, simulator will skip th

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

> We should get rid of long-running unit tests altogether. They should run > faster or be split. I think we just need to evaluate on a case-by-case basis. Some tests are bad and need to go. And we need other/better ones to replace them. I am deliberately not making examples here both to avoid c