[development] idea for an install profile (and "distribution"):devel install

[Larry Garfield]

Derek, that is a totally awesome idea.  I actually just finished writing my first install profile for our internal use at my company (and need to report a few bugs from the process yet), so profiles and macros have been up in the front of my mind this week.  Very often I'm developing modules against a real site I'm building, but I agree that having a test harness environment with dummy data to test against ready-to-wear would be very helpful.  Encouraging the use of unit tests is a good thing, too.

Before we get into a debate over which modules should be part of this "stress testing" profile (not being a pessimist, just a realist <g>), my I suggest two different environments?  One for normal development and one for security stress testing.  There are some things that the security stress tester may do that could make normal development more difficult.  OK, I know that sounds lame now that I read it over again, but I can see the performance hit and mental overhead hit of having a security test suite running every time I tweak one variable being highly annoying and slowing me down, even though I see the great value of running it through a security-testing environment before releasing.

--Larry Garfield

On Wed, 28 Feb 2007 01:59:11 -0800, Derek Wright <drupal at dwwright.net> wrote:
> while waiting for Dries to officially RTBC the issue for hosting
> install profiles on d.o [1], i just had an idea for a install
> profile: the development profile.  things it could do:
> 
> 1) install/configure devel.module
> 
> 2) setup some standard roles for testing (non-uid-1 admin, content
> admin, a role that only has "switch users" permission, etc), and
> configure all perms appropriately.
> 
> 3) create a small pool of users in each of the roles, all of which
> are also in the "switch users" role, enable the switch users block
> from devel.module, etc. [2]
> 
> 4) also create a bunch of random users with the generate script from
> devel.module...
> 
> 5) create a bunch of test content with the generate script.
> 
> 6) create a bunch of malicious (XSS-seeking) content: node titles,
> taxonomy terms, anything we can think of that some module might not
> be escaping properly somewhere.  basically, wrap js alert boxes
> around just about any possible user-input we can find. ;)
> 
> 7) install as much of the simpletest.module and framework as
> possible, and otherwise prompt/warn the user about the external
> library they should download and install.
> 
> 8) perhaps install some per-node-access module(s) (tac_lite,
> simpleaccess, etc) and configure some of the auto-generated content
> to be private.
> 
> 9) optionally install some other handy modules folks use for testing
> (i'm a big fan of diff.module and dba.module, but there might be
> others that would be useful).
> 
> 10) perhaps install/configure some kind of benchmarking tools (if any
> exist that would be appropriate).
> 
> ...
> 
> 
> this would:
> 
> a) save a ton of time whenever one of us needs to setup a local test
> site
> 
> b) make it *much* easier for newer developers to get a standard test
> environment up and running
> 
> c) facilitate being able to reproduce bugs, since everyone could be
> working from a more standardized test environment most of the time
> 
> d) lower the barrier to developers running (and therefore writing)
> simpletests for their code
> 
> e) help find XSS more quickly, since folks (and automated tests)
> would be navigating through a site that was trying to XSS-ify itself
> all over the place.  just having the per-node-privacy content auto-
> generated would help remind folks to test those sorts of edge cases
> in their code, too.
> 
> 
> i don't have time to work on this, but i'd be willing to help someone
> (s) else.  or, if anyone thinks this is such a good idea, they want
> to pay me to work on it instead of my other consulting gigs, that
> might work, too. ;)  if we could stand to wait that long, this might
> make a nice SoC 2007 project, too.
> 
> thoughts?
> -derek
> 
> 
> [1] http://drupal.org/node/113939
> 
> [2] it'd be nice if there was a setting in devel.module to restrict
> the choices in the switch user block to users that have 'switch
> users' permission, so that such a test environment would always allow
> you to quickly switch back and forth across differently perm'ed
> users, without ever getting "stuck" on a random user that didn't have
> switch perms...