The point of a test site is to have a place to experiment or develop new content without impacting your users or giving away your latest gee-whiz before its time. But it is also important to make sure that you always have a good working version of your live site on your test site.
Let's ignore, for the moment, that in an "ideal" world you will have a staging site which is always identical to the live site and nothing goes live without being staged.
There are two basic techniques for keeping your sites synchronized:
- Manually making sure that the content of the two sites are the same.
- Frequent uploads or downloads of database back ups.
The first technique is quite time consuming and it's difficult to keep user comments on your test site. It also relies on your memory to know what's been changed, unless you update both sites at the same time. If there are things that are dependent on other things (sorry for the technical terminology), you have to be careful that you update them in the right order so that your random visitor doesn't break something.
The second technique allows for user comments to be downloaded to your test site. From there they can be incorporated into the content and deleted, or left as is. You just have to be careful that you don't lose new, experimental, or incomplete content that hasn't been put onto the production site yet.
Which is better? I can't answer that question for you. You need to weigh the risks and benefits and decide that for yourself. Personally, at my age and with my memory, the second technique is probably better for me, at the risk of losing something not yet uploaded. I also have the bad habit of updating things on the live site and not bringing the changes back to the test site.
NOTE: the following is more advanced and not part of the original Cookbook:
You may want to review the following modules which can assist with migrating database changes:
You might also consider development using tools which allow feature sets to be stored in files so they can be applied to other site databases:
Some modules, like CCK and Views provide means to export their settings so that they can be applied to other sites. In combination with custom implementations of hook_update_N, this can provide an automated way to migrate some kinds of database changes.
To read more discussion on this topic you can read this post by Larry Garfield