views:

41

answers:

3

Let's say I have a (fairly typical) set of environments: PROD, UAT, QA, DEV. Is it a good idea to run your tests across all environments?

Here's what I'm thinking of. I have a proc in SQL that my code depends on, I'll call it proc_getActiveCustomers. If that proc isn't present my app will go south real fast. So I write a test that checks for the existence of this proc in the database. Nothing new here.

But when I then deploy my app to the QA environment, would I also want to have a test that checks that environment for the existence of proc_getActiveCustomers? I think this is a good idea but I've never heard much about testing in environments outside of development. Makes me wonder if there's some downside I'm not aware of.

The direction that I'm going is to have a list of environments in code and then passing that environment into my unit test.

+5  A: 

This is called a smoketest, and IMHO it is a good idea in your case (too).

A smoketest is a quick (set of) test(s) to ensure that the product is installed correctly and basically seems to be in a working condition. As opposed to integration, load etc. tests which are much more thorough, consume resources, and often alter the state of the system in undesirable ways, therefore are not suitable in a production environment.

Péter Török
Ahh, thanks. I was thinking these didn't seem like integration tests or unit tests. Now I have something to call them.
jcollum
@jcollum: I've never heard the smoke test term used in a formal context, so you may want to think about when/where you use it (or at least spell out what it means if you're talking to a non-technical sort of person).
GreenMatt
@GreenMatt, good point. For management and users, it might be better to call it "build verification test".
Péter Török
A: 

The test you're talking about does not seem like a "unit" test to me. It checks that your setup is correct. I would certainly include the check in the application initialization code and make it create the stored procedure in case, but I would not call it a "test" in the TDD sense.

It's like running a checklist to see if all of your components were installed correctly.

The unit test should check if the component works as intended, not if it's there...

Manrico Corazzi
A: 

You're drive should be to get the application into a deployable situation. I would say that everything simulates a production environment. If your app has this dependency (real, mocked, subbed, or faked) it should always be tested. You might want to check out Continuous Integration. It might help you with delineating whether you need this test.

Gutzofter
Agreed, CI would be an excellent solution. Some resistance to adoption of that around here.
jcollum