Do you test new modules before uploading them to your live site?

To not test modules is madness! Down that road lies peril!

FunnyMonkey
Click. Connect. Learn.
Using Drupal in Education

uploading modules to live site without testing is inviting problems home :)
Asif
Azri Solutions (http://www.azrisolutions.com/)

I do, but not manually. Unit tests do it for me.

I am toying with the idea of burning in modules before I build custom code around them. What I mean is, take a contrib module, plop it in my test environment, enable it, but make no use of the functionality. Do some basic regression (or test other new changes and thereby test the module). Then push it up to production.

I should be able to see if the module has any memory leaks or other big problems before I both writing custom code to integrate this module into my site. does anyone else do this, and does it make sense to you?

Johnny

Yes - always test first. If the module does database queries I also check to make sure they aren't doing anything too nasty (ie: filesorts, temp tables, no index, etc.)

This is kind of relative :D

I'd answer this as on big it depends(All sites does not have the same priorities).

So for example, if you really need to build a site for collaborating, hear that og can do it, and it would live not so many time(this is relative too) you do not want to test all code you need, because it is time consuming. But if you want to build a decent middle size, kind of longer life site, you really want to test all you can.

Well, I think answers may differ a lot because we all do not have the same idea of testing.
Some approaches to do that:

• just try it and verify it does not break the site(maybe usually in non-tech drupal end users)
• run simpletest tests
• reads the code and verify if it's enough efficient
• try to bring it down to prove security

.. it could be a really big list, but, I think the idea is clear.

If you are working on your personal site, and can tolerate a catastrophic failiure (i.e., have a good, current backup) then perhaps you can live without testing.

If you are doing work for clients, it could be considered negligent to not test in a staging environment before deploying new and/or updated code.

Probably, there's people that do not test, but I think most of us do, so the question would be how far you go when testing modules before deploying them on production?

For example, I do not only test, but also read the code, and look at the issues queue, the project stats, the background of the module author, etc. There maybe things here that tell me it's better to find an alternative to a certain module. It depends on how critical it is for the project I'm working on too.

Using this method I've found bugs several times, and depending of several factors, I may opt to report them, or even try to fix them, or just forget and try alternative modules, etc.

I never maintain a website without separate production and development branches. No one should ever get into the habit of deploying untested changes to a production site. Its these bad habits that cause huge headaches and are hard to break on a conceptual level when you're trying to grow and expand.

So yes. I always test. I make my changes in a development environment and when things seem to be working fine, I'll then merge with production.

Being an old QA guy in various dev & webdev environments, my background is testing. I actually find just as much pleasure in testing out a new module as I do in the moment that I fully deploy to production. Both are fun & rewarding. While unit testing gets the job done lots of the time, I like getting down & dirty with manual testing. I usually feel confident in my breadth of testing & end up learning a thing or 3 about the module to boot!

I actually find it hard to believe this isn't a joke question. Unless/until you have deep familiarity with a particular module, installing it on a production site without IN-CONTEXT system testing is practically suicidal - especially if you are dealing with Drupal 6. (sorry, but still true!) I say "in-context" because when you run into serious conflicts, they will usually be between 2 contributed modules. The only way to do proper system testing is to use a dev/staging server with a similar setup to the production machine. If the client does not have a staging server, I use one of my own.

We were testing a module the other day that had an uninstall routine so thorough that it pretty much uninstalled our dev server. Not good, embarrassing, but not too painful either -- svn up and some config restores from backup fixed it. Certainly would have been nasty on a production site.

I almost always test during development on a dev/staging server which is sometimes a test domain on the same dedicated server that I end up putting the client site on. But sometimes I just go for it and place a contrib module on a live site and hardly check anything, but that is usually a module I've reused over and over and know fairly well. Plus a little version control goes a long way.

We've got a dev server to screw around on, and a QA server that is designed to be very similar to production. All code gets tests on the QA server before going live. (In fact, because of the way the deployment scripts are set up you pretty much have to deploy to the QA server first.) Some day I'll get around to setting up an automatic run of simpletest.

I always set up a local development environment and I create a clone and make it live or you can say the live site is the clone of my local pack.
If some thing goes wrong, the live site will not have any effect since I test it on my local pack.

:)
Beautifulmind

Maybe I'm a bit mad but I work with a lab where I tested everything I need.
Them I move to pre-production, where I check that It works fine with the customers web
And then I go to customers website.

It's a little slow, but I have never a problem with a customers website.

oskar