Global starting point for factory.Sequence counters

After reading the documentation it seems there’s no supported way of defining a starting point for all factories. I’m looking for something similar to:

factory.COUNTER_START = n
obj1 = SomeFactory()
obj2 = SomeFactory()
obj3 = SomeOtherFactory()
assert(obj1.someattr == factory.COUNTER_START)
assert(obj2.someattr == factory.COUNTER_START + 1)
assert(obj3.someattr == factory.COUNTER_START)

When running the tests it helps in having an unique COUNTER_START per process so you can run similar tests in multiple processes without having database conflicts; also if you want to preserve past test data and re-execute tests.

Right now it seems all the classes need to be modified to take something like COUNTER_START into account, so this issue is about having a helper that does that for all the factories (maybe a factory could optionally want to disable the feature though?).

[rbarrois]

@gpip Even if this does not match typical factory_boy use cases, I see how that could be useful, mostly for the “multiple parallel runs of tests in threads”.

So, if you’re ready to provide the code, I’d be glad to help you along 😉

A good starting point would be BaseFactory._setup_next_sequence() in factory/base.py.

[gpip]

Can you describe the columns/unique constraints a little more?

Let’s simplify the situation and assume there’s one database which does not get dropped between test runs. So this database X has a table U, and U has an unique field named username.

Using FactoryBoy I create a class attribute to define an username exactly like this one: username = factory.Sequence(lambda n: 'user%d' %d). It seems to be doing it in a similar way to what you mentioned, tackling an integer at the end. Now, I could go further on this and do exactly like you: pick a word at random from a dictionary instead of prefixing with “user”. But if I run tests that use this many times (remember, in this example the database is never dropped), I still have a good chance to hit a conflicting username.

But, what’s n for FactoryBoy? What if n was the current timestamp? If n was the current timestamp then I could re-run the same tests forever without conflicting on usernames (assuming the machine(s) is/are running ntp, etc).

In the situation where there is a single database which gets dropped between test runs but multiple processes hitting it, n would start at 0 for each process and the tests would cause expected integrity errors. If n started with (just making a guess here) the PID || timestamp then, again, the tests wouldn’t run into conflicts. The exact process of defining a starting point depends on how you manage test runs, if you can pass an integer (starting from 0) to processes/threads you’re spawing then prepend that to the timestamp as a string to avoid the integrity errors.

All of this does not really matter if you’re using x processes and each one uses its own copy of database X, since you can start all counters from 0 and they will not run into the problem.