You're welcome!

Yes, you will need to write a test class in order to deploy it. Triggers require at least 75% code coverage for the trigger itself, as well as at least 75% global coverage in the organisation to deploy to...

Thankfully, this is a very simple trigger to test for. 

Apex testing is a whole other kettle of fish that many amatuer coders tend to underestimate the value of.

Poorly architected tests can cost huge amounts of man hours as your organization grows. As a consultant, I commonly have to augment client applications that are made up from other consultants, or the clients themselves. Sadly, most of the time, it is not done correctly, and the man hours I burn fixing improper code, and ensuring test coverage must be passed on to the client to pay for.

Added to that: the vast majority of free sample code out there has test classes that are poorly architected... Here is how I would cover this code:

1) Create a class that will store your test object records. From what I know of your system, you will need at least two records. The class would look as follows:

public without sharing class TESThelper {

/*
Use this class to help create static objects in Test classes...
DO NOT create records inline in test classes

NOTE all properties are alphabetical by object
*/

	//A simple Destiny_Products_and_Services__c
    public static Destiny_Products_and_Services__c  testDestiny00 {
        get {
            if(testDestiny00 == null) {
                testDestiny00  = new Destiny_Products_and_Services__c(
                    name = 'testDestiny00',
					Product_or_Service__c = testProduct00.id
                );
                insert testDestiny00 ;
            }
            return testDestiny00 ;
        }
    } 
	
	//A simple product
	public static Product__c testProduct00{
        get {
            if(testProduct00 == null) {
                testProduct00  = new Product__c(
                    name = 'testProduct00',
					Product_Name__c = 'EXAMPLE PRODUCT NAME'
                );
                insert testProduct00;
            }
            return testProduct00;
        }
	}

}

 Note my naming convention. I keep all test and test related classes prefixed with the name 'TEST' so that they're easier to view and sort etc...

This class will grow as your org grows with tests. Anytime you need to create records to cover apex code, those records definition should be put in here in the same fashion as the examples i've placed.

NOTE: that if you have some required fields that I don't know about, you would need to add those to these two records as well. This is just a framework.

By creating all objects in once place, and havint your test classes reference all the same objects, you avoid having to recode every single test class when you make a change to a business rule.

Next, create your test class to cover the trigger:

@isTest
private class TESTdestiny_bIbU {
    static testMethod void myUnitTest() {
        Destiny_Products_and_Services__c d = TESThelper.testDestiny00;
    }
}

 That's easy. We know it's covered because all the trigger does is set a value from the record in one field to another field. So there is really nothing else to do. this should get you to 100% coverage.

Again, notice the naming convention: TEST then I put the name of the trigger I'me testing against. This way, there are no questions as to what this test is supposed to accomplish, because it is defined by the very trigger process it covers.