function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
tggagnetggagne 

Have you ever created a custom object ONLY for unit testing?

Have you ever had to create a custom object just so you could test generic functionality inside your Apex code?  

I need to test creating and saving an object (in any org) but every object might have workflow rules, required fields, or triggers connected to it that would break the unit tests.

We're thinking of creatoing a custom object, appropriately named, that we can use for testing basic object creation and insert/updating.  

I want to avoid creating unnecessary clutter.  If you know of a Salesforce object that is immune to triggers, workflow rules, or required fields that a unit  test could use in /every/ Salesforce organization (except professional), let me know.

Otherwise, what do you think of creating a just-for-testing object or have you ever done it before?
PrasanntaPrasannta (Salesforce Developers) 
Hi,

Well its a good idea to create a custom object but we need to write some trigger or apex class to write the test class.
We need to have atleast 75 % code coverage of the test class to move it into production.

Please  go through this link below
http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_qs_HelloWorld.htm

This link that will guide you with the following-

1. How to create the custom object.
2. How to write the apex class.
3. How to add an apex trigger
4. How to write the test class.

This will give you the clear understanding of how to write the test class and how it works.
tggagnetggagne
Thank you, Prasannta, but I must not have made myself clear.

I have a class that works with generic sobjects.  In its unit tests it tries to create and update rows to the object.  It works well and coverage > 85%.

My problem is every org is different.  If I write my test using Account, Contact, Opportunity, or any other standard Salesforce object, its unit tests may fail because customers can add any required field they wish, or create workflow rules my unit test can't predict.

I repeat, the unit test isn't picky about what object I select as long as I pick one.

To get around dependencies on standard objects and the complications that accompany them, I could deploy a custom object of my own--but it's only purpose would be for the unit test, which makes me uneasy as I'm introducing clutter into a customer's org.

So I'm back to wondering, wouldn't it be great a unit test could create a custom object just for the purposes of testing adds and updates, then have the custom object disappear when the unit test is done, just like its test data does?