Launchpad itself

Merge lp://staging/~mbp/launchpad/891028-notunique into lp://staging/launchpad

  1. 891028-notunique
  2. Merge into devel
Proposed by Martin Pool
Status: Merged
Approved by: Martin Pool
Approved revision: no longer in the source branch.
Merged at revision: 14312
Proposed branch: lp://staging/~mbp/launchpad/891028-notunique
Merge into: lp://staging/launchpad
Diff against target: 41 lines (+4/-10)
1 file modified
lib/lp/testing/factory.py (+4/-10)
To merge this branch: bzr merge lp://staging/~mbp/launchpad/891028-notunique
Reviewer Review Type Date Requested Status
Michael Hudson-Doyle Approve
Review via email: mp+82480@code.staging.launchpad.net

Commit message

[r=mwhudson][bug=891028] don't assume random integers are unique

Description of the change

"Unique" integers from randint won't always be unique: use a global counter to try to make sure they actually are unique.

To post a comment you must log in.
Revision history for this message
Robert Collins (lifeless) wrote :

Can't you just use testtools.TestCase.getUniqueInteger? That should be
unique across the process lifetime.

Revision history for this message
Martin Pool (mbp) wrote :

> Can't you just use testtools.TestCase.getUniqueInteger? That should be
> unique across the process lifetime.

No, that's only unique per test.

That ought to be enough if the tests are well isolated, but I wouldn't be surprised if there are some that actually do rely on the names being unique across tests.

Also that requires a TestCase object, and we don't easily have one in the ObjectFactory.

The implementation is basically the same (a counter) and the code is so small having it here doesn't seem so bad.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Seems like an improvement to me. If tests fail because of this, some people need an education :-)

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.