From a testing point of view, the most realistic testing environment is a current copy of an actual production database. There are sometimes apparently good excuses about why it is just too difficult to test using a copy of the actual production database.

Remember, when we implement our modifications, they will receive the test by fire in the environment of production. We need to do everything within reason to assure success. Let's review some of the potential problems involved in testing with a copy of the production database and how to cope with them:

• It's too big: This is not a good argument relative to disk space. Disk space is so inexpensive that we can almost always afford plenty of disk space for testing. We should also make every possible useful intermediate stage backup. Staying organized and making lots of backups may be time consuming, but done well and done correctly, it is less expensive to restore from a backup than to recover from being disorganized or having to redo a major testing process. This is one of the many places where appropriate use of the C/AL Testability tools can be very helpful by allowing various approaches to repetitive testing.
• It's too big: This is a meaningful argument if we are performing file processing of some of the larger files, for example, Item Ledger, Value Entry, and so on. However, NAV's filtering capabilities are so strong that we should relatively easily be able to carve out manageably sized test data groups with which to work.
• There's no data that's useful: This might be true. However, it would be just as true for a test database, unless it were created expressly for this set of tests. By definition, whatever data is in a copy of the production database is what we will encounter when we eventually implement the enhancements on which we are working. If we build useful test data within the context of a copy of the production database, our tests will be much more realistic and, therefore, of better quality. In addition, the act of building workable test data will help us define what will be needed to set up the production system to utilize the new enhancements.
• Production data will get in the way: This may be true. If it is especially true, then perhaps the database must be preprocessed in some way to begin testing or testing must begin with some other database, such as Cronus or a special testing-only mockup. As stated earlier, all the issues that exist in the production database must be dealt with when we put the enhancements into production. Therefore, we should test in that environment. Overcoming such challenges will prepare us to do a better job at the critical time of going live with the newly modified objects.
• We need to test repeatedly from the same baseline or we must do regression testing: These are both good points, but don't have much to do with the type of database we're using for the testing. Both the cases are addressed by properly managing the setup of our test data and keeping incremental backups of our pretest and post-test data at every step of the way. SQL Server tools can assist in this effort. In addition, the C/AL Testability Tools are explicitly designed to support regression testing.

Remember, doing the testing job well is much less expensive than implementing a buggy modification and repairing the problems during production.