Merge lp:~bjornt/launchpad/more-unique-factory-strings into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Graham Binns on 2010-05-18 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 10887 |
| Proposed branch: | lp:~bjornt/launchpad/more-unique-factory-strings |
| Merge into: | lp:launchpad |
| Diff against target: |
20 lines (+2/-1) 1 file modified
lib/lp/testing/factory.py (+2/-1) |
| To merge this branch: | bzr merge lp:~bjornt/launchpad/more-unique-factory-strings |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Graham Binns (community) | code | 2010-05-17 | Approve on 2010-05-18 |
|
Review via email:
|
|||
Description of the Change
Make LaunchpadObject
Currently LaunchpadObject
an instance. This is fine for tests, but not so good when using it to
generate test data for manual testing. I've often run into the situation
where I use the object factory to generate a number of objects in a
script. After a while I want to generate more objects, but it fails,
since the it tries to use the same names as before. With this change
it's quite unlikely that it will use the same names twice, even though
there's still a small risk. If we see a test failing due to this, we can
quite easily make sure that it's really unique within an instance, by
keeping track of generated uuids.
One benefit of this change is that it makes sure that people don't
hardcode automatically generated names in the tests. I might have to fix
some existing tests; I've not finished running the test suite yet.
| Jonathan Lange (jml) wrote : | # |
| Björn Tillenius (bjornt) wrote : | # |
On Mon, May 17, 2010 at 02:28:30PM -0000, Jonathan Lange wrote:
> 2010/5/17 Björn Tillenius <email address hidden>:
> > If we see a test failing due to this, we can
> > quite easily make sure that it's really unique within an instance, by
> > keeping track of generated uuids.
> >
>
> Or you could drop the uuid approach and simply put id(self) into the
> string before the getUniqueIntege
I'd rather stick with uuid, since id() seems to be to prone to generated
duplicates:
>>> def foo():
... foo_factory = LaunchpadObject
... print id(foo_factory)
...
>>> foo()
124609680
>>> foo()
124609680
If I would have used id(self) and used the factory to create objects in
foo(), it would have failed the second time.
--
Björn Tillenius | https:/

2010/5/17 Björn Tillenius <email address hidden>:
> If we see a test failing due to this, we can
> quite easily make sure that it's really unique within an instance, by
> keeping track of generated uuids.
>
Or you could drop the uuid approach and simply put id(self) into the r()-generated segment.
string before the getUniqueIntege
jml