On Mon, Feb 10, 2020 at 04:08:40PM +0100, Stefano Brivio wrote: > On Fri, 7 Feb 2020 11:34:42 +0100 > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > On Thu, Jan 30, 2020 at 01:16:58AM +0100, Stefano Brivio wrote: > > > This test checks that set elements can be added, deleted, that > > > addition and deletion are refused when appropriate, that entries > > > time out properly, and that they can be fetched by matching values > > > in the given ranges. > > > > I'll keep this back so Phil doesn't have to do some knitting work > > meanwhile the tests finishes for those 3 minutes. > > But I wanted to see his production :( I'm not good at knitting, always liked crocheting more. That said, I like fast testsuites more than any of those. ;) > > If this can be shortened, better. Probably you can add a parameter to > > enable the extra torture test mode not that is away from the > > ./run-test.sh path. > > I can't think of an easy way to remove that sleep(1), I could decrease > the timeouts passed to nft but then there's no portable way to wait for > less than one second. > > Probably a good way to make it faster and still retain coverage would > be to decrease the amount of combinations. Right now, most of the 6 ^ 3 > combinations (six "types", three values each to have: single, prefix, > range -- where allowed) are tested. I could stop after the first 3 x 3 > matrix instead, if we come from run-tests.sh. > > Let me know if you have other ideas, otherwise I'd send a patch doing > this. You could test the timeout feature just once and for all? I doubt there will ever be a bug in that feature which only a certain data type exposes, but you may e.g. create all the sets with elements at the same time so waiting for the timeout once is enough. Cheers, Phil
