In a production environment, the Force.com platform requires you to create unit tests that execute your code and assert that it's working correctly, so that at least 75% of your Apex class and trigger code is covered by tests.

Your Enterprise Edition licenses include a Developer Sandbox environment for writing your code and unit tests.  In a Sandbox, you can freely develop Apex classes and triggers, regardless of test coverage.  When you're ready to move your code to production, you can use any of several methods to deploy them, such as the Force.com IDE's Deploy to Server wizard, the Force.com Migration Tool plugin for Apache Ant, or the new browser-based Cloud Deploy (aka Change Sets) under Setup > Deploy.

When you deploy to production, you will need to include your classes, triggers, and test classes together in one set.  The server will execute all of your tests to make sure they pass and to verify the overall code coverage %.  Note that it runs all the tests in your production organization, not just your new ones--so if your new code causes an existing test to fail, your deployment will abort and roll back.  This helps ensure you do not make unintended changes to your production environment that would break existing functionality you have previously deployed.

One common reason for tests to fail on deployment is how you use test data.  Your Apex code should contain no hard-coded references to IDs.  You should create all the data you need for your tests within your test methods, so that the test can run independent of any specific data that may or may not already exist in the system.  Otherwise, if your tests expect some particular record to exist in the organization, when you work in one place but deploy to another the test may fail in the second environment (e.g. production).

Jon

salesforce.com Product Manager