On Thu, Mar 26, 2009 at 11:59:34AM -0700, Ovid wrote: > --- On Thu, 26/3/09, chromatic <chroma...@wgz.org> wrote: > > > From: chromatic <chroma...@wgz.org> > > > That's the only reason I wouldn't do it, either -- and in that case, > > I'd try to find a way to make screwing up production data > > impossible. Some people see reasons why you can't or shouldn't run > > tests on production machines. I see obstacles to remove. (Note > > that that attitude doesn't always work.) > > That's the main reason why our tests don't run on production right > now. I would like, at the very least, to have a './Build sanity' > target to ensure that guaranteed non-destructive tests are run, but
I am moving in this direction too, but to be safe in production this is the default testing mode. This is just a small matter of configuration though. > the strange argument I'm facing is that "production should be an exact > copy of staging and thus tests on staging should be enough". I agree with the premise, and as such my tests don't get run in the final pre-prod environment either. I do appreciate however, that not everyone may have as many testing environments to play with as I do. And if production should exact copy of staging, then shouldn't the tests that get run in staging also get run in production? > I want those tests, but the people arguing are huge Java fans and > argue that "Java is safe to deploy, why not Perl?" I'm not sure it really has anything to do with language. The main app I'm working with has perl, java, C++, PL/SQL, groovy, shell, proprietary 4GLs and who-knows-what-else. I tend to treat them all the same as far as QA is concerned. I think it's just that as a broad generalisation Perl seems to have much more of a testing culture than many other communities. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
