Populating systems under test with data is often done by cleaning and inserting data directly into databases using SQL scripts. Whilst this technique is simple, it can have several drawbacks for automated tests.
Learn how to combine the Data Test Builder Pattern with the web services exposed by your application. This hybrid implementation of the pattern can then be used to populating test data without direct database access.
Video producer: http://www.seleniumconf.org/
I’m a huge fan of the Test Data Builder pattern, and I think this pattern I first saw this pattern in Growing Object Oriented Programming. I think it provides a great DSL for creating test data locally. I would caution anyone from too tightly coupling it with database calls or api calls, but it can be a piece you use as part of a factory or module that handles setup and tear down.
As far as uniqueness goes, I tend to avoid using random numbers, since there’s no guarantee that in a given set of n tests run concurrently that there won’t be a numeric collision, I instead favor a timestamped approach. But I think you’ve given a very good synopsis on the pattern, and how it might be used. I think cleanup and generating of Ids, if you can manage that later, may save you some in run time, but I subscribe to a the notion that its best to cleanup when you can. Things work better if you’re in an environment where the new deployment environment, also resets up a base database for use, which IMO means you could ignore some of the cleanup parts.