rename possibly identical modules to prevent test collisions

[mattip]

Fixes #134 by renaming the test module, if not already specifically named. I needed two randint invocations to reduce the chances of collision.

[arigo]

I don't know what to do with the failures shown here on macosx. I'm not sure if they are relevant, and if not, I'm not sure how to say "merge anyway please".

[arigo]

Also, not sure why you use randint(32000); I would replace that with randint(1000000000) and still call it twice. It costs nothing and reduces the risks more.

[mattip]

OK. I can reproduce the failures locally. That test seems specifically designed to reuse the module, note how the lib2 code is exactly the same as the original one.

[arigo]

Still fails. Maybe differently?

[mattip]

All of test_verify.py, test_vgen.py, and test_vgen2.py call cffi.verifier.cleanup_tmpdir() at module setup. If another thread/process is running these in parallel, the cleanup may happen when another test is running. But that is a second-order problem, it should only cause slower test runs 🤞

[arigo]

Still failing...

[mattip]

CI is passing. I think randomizing module names now makes the test_vgen2.py test irrelevant. Thoughts?

[arigo]

Yes, that's bad. I don't remember any failure caught specifically by test_vgen2, but its point was precisely to reuse the modules.

[arigo]

This dooms the whole approach, I'm afraid. We need either to say pytest-xtest is not supported, or decide test_vgen2 is not very useful and kill it, or maybe find a proper refactoring.

[mattip]

Is it important that all the test_vgen tests be rerun without *.c sources, or can I add a specific test for a single case of removing the *.c source and running verify again, and actually check that the source is not regenerated? As far as I can tell, test_vgen2 does not actually check that the source is unneeded, so I am not sure what it is designed to check.

[arigo]

I may originally have decided that I would notice if test_verify2 took as long to execute as test_verify instead of being very fast, just because I was running the tests locally.

If you want to kill the test_v*2.py files and replace them with a single test that checks no C code is regenerated, then I'm fine with it.