I did cargo t on this branch and I feel the test duration is a bit prohibitive.

waiting 70s or even 250s for a test to finish its execution feels a bit too much.

but also, I don't see any fundamental reason that forces us to do this

I mean, sure, expected share rate is set on a per-minute basis for UX reasons, but that doesn't mean that we must test scenarios for multiple minutes to assert the sanity of the APIs

if we remember that all math done here is linear, we can simply tweak these constants in order to allow us to perform our simulations under smaller execution timespans

for example, if TEST_SHARES_PER_MINUTE is 60_000, we expect 1_000 shares per second

if in 1 second we only get 10 shares, that should be a trigger to lower the difficulty

if in 1 second we get 5_000 shares, that should be a trigger to raise the difficulty

if we want to emulate scenarios of "long" timespans, we can do ~10s

overall, we have plenty of room to play around with magnitudes, while trying to optimize for test execution time

ok I see the minimum window we have is 15s

@GitGab19 I assume this is important for the correct behavior of the algorithm, right?

if so, then we can still make test durations much smaller, sticking to 15s as the default execution time and making artithmetic adaptations around TEST_SHARES_PER_MINUTE

I’ve added a test configuration for this, which will also allow delta_time <= 0 in testing scenarios.

Although the linearity seems tempting to exploit for testing, there’s a fundamental reason we need to wait for this duration our logic is designed to trigger at specific time intervals. Anyway, I’ve updated the tests to specifically target those wait points, and they’re now more intuitive to understand. The downside is that we still need to wait at least 60 seconds for those points to be reached. I initially considered adding some test-specific logic to bypass this, but that felt like heavy lifting given the current setup.

I see tests to assert target increase and decrease

but I don't see anything asserting that the vardiff converges to a correct hashrate estimation?

I understand your point about the convergence test. I’m planning to add that in a separate PR since it will require more work. This PR focuses on adding the basic skeleton for the testing framework for the vardiff module and strictly handling edge cases in the vardiff calculation. We already have a convergence mechanism in the difficulty management of tproxy, but it's somewhat unreliable. Also, simulating the entire hashing process is influenced by variable processing speeds, which makes it tricky. Designing such tests to be deterministic across the system would need a more careful and thorough review.

when I wrote this comment originally, I wasn't necessarily thinking about dynamically testing with real hashrate from a CPU miner

my mindset was more around statically running the tests with specific values, such that we can assert that the vardiff algo converges into the right direction on its hashrate estimation