Plugin Development: WPMU or WP?

You’ll need to test in both setups, because they behave differently in a lot of situations. Some of the most notable differences are:

1. If you register an activation callback, you need to check if the activation was network-wide. If it was, run the activation logic for all the blogs instead of just the current one.
2. If the plugin is network-activated, the regular activation callback won’t fire when new blogs are added, so you’ll need to create an additional callback that hooks into the wpmu_new_blog action. It has to switch to the new blog, do the activation logic, and then restore the current blog. The $id of the new blog is passed in to the handler as the first parameter.
3. If you’re creating a custom post type and want the Set Featured Image meta box to show up, you’ll need to ensure the Media Upload Buttons setting has the Images checkbox enabled. You can use get_site_option( 'mu_media_buttons' ) to check it and update_site_option() to set it.
4. The path to the uploads directory is different, but you’ll be fine as long as you always use wp_upload_dir() instead of the constants.
5. Each blog has it’s own copy of most of the database tables, and they’re prefixed with the blog ID. You don’t typically need to do anything special, though as long as you’re using the API to interact with the database — which you should, whenever possible.
6. The users and usermeta tables are the exception; they’re shared across all blogs.
7. There have recently been a few WP-Cron bugs[1, 2] that only affected jobs on MultiSite installations.

You can use switch_to_blog() if you need to temporarily access another blog’s data with API functions, and then restore_current_blog() to switch back.

You can see a complete example of the activation functions by browsing the source of my plugin skeleton.