Launchpad itself

Bug #663520
Comment #2

Comment 2 for bug 663520

Revision history for this message

Gary Poster (gary) wrote on 2010-10-20:

Thanks for the comments, Robert. Diogo copy and pasted some old notes on this here at my request so that we wouldn't lose the idea, even while we have decided not to pursue it now. We'll definitely circulate this more if/when we start to think about scheduling this. That said, I'll reply now to these particular concerns.

To take a step back, why are we interested in this kind of thing?

Big goals:

- We want to be able to have these tests create what they need to.
- We want to be able to run the same tests on staging and dev, as close to transparently as possible.

Smaller goals:

- We only want to work on this when we have a concrete need to--when a top-tier webservice app needs the feature for a test.
- We want it to be easy to write these tests.
- We want the tests to have some known approaches that can speed them up.

(We can take a further step back and talk about rationale for these goals if you like, but I'll take it as a given for this reply that we agree that these are valuable goal. The second big goal--be able to run the same tests on staging and dev--is the most arguable, AFAIK, but it's stood the test of the discussions so far.)

Those goals don't have to lead to the bug description as it stands now. As you said, we can create objects on staging. That's true.

The one thing we've identified that we can't do easily on staging is create new users, with different permissions.

To the best of our knowledge so far, a minimal, and perhaps sufficient, implementation of these goals would be to make it possible to easily create new users and log in as them on staging and dev, in tests. We might need to go further, and be able to give the users special privileges, depending on the webservice test.

A similar approach that might be easier to implement would be to have only sample data users only--a normal user, and maybe an admin user or other special users--that are available for users to log in as in staging and dev. Being able to create users seems like it would be nicer, for reasons like being able to better control the expected results of various webservice calls if you have created the user from scratch. Maybe also we would have performance issues if multiple scripts were logged in as the same person; I don't know.

Neither of these would necessarily require the blacklist change or sample data objects, per your listed concerns.

Anyway, that's our thoughts so far.

Thanks for the comments, Robert.  Diogo copy and pasted some old notes on this here at my request so that we wouldn't lose the idea, even while we have decided not to pursue it now. We'll definitely circulate this more if/when we start to think about scheduling this.  That said, I'll reply now to these particular concerns.

To take a step back, why are we interested in this kind of thing?

Big goals:

- We want to be able to have these tests create what they need to.
 - We want to be able to run the same tests on staging and dev, as close to transparently as possible.

Smaller goals:

- We only want to work on this when we have a concrete need to--when a top-tier webservice app needs the feature for a test.
 - We want it to be easy to write these tests.
 - We want the tests to have some known approaches that can speed them up.

(We can take a further step back and talk about rationale for these goals if you like, but I'll take it as a given for this reply that we agree that these are valuable goal.  The second big goal--be able to run the same tests on staging and dev--is the most arguable, AFAIK, but it's stood the test of the discussions so far.)

Those goals don't have to lead to the bug description as it stands now.  As you said, we can create objects on staging.  That's true.

The one thing we've identified that we can't do easily on staging is create new users, with different permissions.

To the best of our knowledge so far, a minimal, and perhaps sufficient, implementation of these goals would be to make it possible to easily create new users and log in as them on staging and dev, in tests.  We might need to go further, and be able to give the users special privileges, depending on the webservice test.

A similar approach that might be easier to implement would be to have only sample data users only--a normal user, and maybe an admin user or other special users--that are available for users to log in as in staging and dev.  Being able to create users seems like it would be nicer, for reasons like being able to better control the expected results of various webservice calls if you have created the user from scratch.  Maybe also we would have performance issues if multiple scripts were logged in as the same person; I don't know.

Neither of these would necessarily require the blacklist change or sample data objects, per your listed concerns.

Anyway, that's our thoughts so far.