All Ideas

Idea Details

Upvoted Downvoted

Post an Idea

This idea has been merged into another idea. To comment or vote on this idea, please visit Custom Metadata Types.

0 Points voting closed

Merged

Robert Nunemaker

Custom Settings should be treated as a Setup Object for APEX Tests

Customization & App Building

With the implementation of API 24, a Test by default must create it's own data. However, that includes Custom Settings. This is very problematic because if we have dozens of Custom Settings that are impacted by the insert of test records, they must all be created to take advantage of the new requirement of creating your own data. Using SeeAllData defeats this and doesn't encourage good test habits. Custom settings should be considered a setup object during tests so that Test plans can see them and we can focus on functionality and the way things are in Production rather than trying to copy dozens of entries for purposes of a simple test.

· Flag

Latest Comment from Salesforce

A.A. Ron - 6 years ago

That is correct, the rows of Custom Metadata Types , being metadata themselves, will be cached and will be accessible through Apex without needing SOQL.

Unfortunately, Custom Settings themselves cannot be upgraded or extended to become Custom Metadata Types. Migrating from Custom Settings will not be easy in some cases. But for many customers and partners the advantages of being able to create metadata rows will out weight the cost of migration.

Flag

Comments ( 18 )

Sort By

A.A. Ron - 6 years ago

Flag

Robert Nunemaker - 6 years ago

I went to this session at DF14, but wouldn't that just be another object/field type? One big advantage of Custom Settings is that they don't cost a SOQL and are cached. Would the new Metadata types provide these advantages? Also, there are many of us with literally hundreds of Custom Settings and retrofitting to this new capability would not be an easy task - especially for a public company as there are SOX implications and regression testing by the business necessary.

Flag

A.A. Ron - 6 years ago

We are working on the sprirt of this request - the ability to create Custom Metadata Types - though not the letter. This will be a new feature, not an enhancement to Custom Settings. I am merging this idea with "Custom Metadata Types."

Flag

Mohammed Khan - 7 years ago

We need this desperately, its hindering our decision to NOT use org data in our test cases.
- Flag

Chandra Lohani - 7 years ago

This is a required functionality. Custom settings should be available in test class with seeAllData=false.
We implemented loading custom settings using .csv and we ran into 'Your runAllTests is using too many DB resources error'.

Thanks

Flag

Scott Eng - 7 years ago

I've been able to stop using the "@seeAllData = true" in my test classes by creating the Custom Settings in my tests, with a utility class.

However, I'm now no longer able to run apex tests in parallel on my sandboxes because various test classes are using the same test data at the same time, causing a ROW_LOCK error. The only way to get around this is to disable parallel testing, causing all tests to run serially as they do when deploying to production, which lengthens the time to run all tests.

Flag

Doug Adcock - 7 years ago

Totally agree - much needed!
- Flag

Sutharsan Pushparajah - 7 years ago

Hi all,

i fully agree with this idea. Actually, we are forced to use the annotation "@seeAllData=true" to enable access to the values. This annotation is like "Evil" for us because it's making test class dependent on datas on each SFDC org. That's not a problem when dealing with developer sandbox where there are not a lot of datas, but when you are deploying to PROD org your test class can go MAD retrieving a tons of datas that you really don't care about in the test context and that can make the test fail because of some limits that are reached.

To overcome this, we use a static resource that we are loading before test starts and this static resource is filling the custom settings.

But we have another problem that still forces us to use "@seeAllData=true". We have managed package that contains protected custom settings that we can't acces. A wsdl must be loaded in order to access object definition that is used by all classes. So here, i'm not able to load the wsdl in test context....

Having Custom Settings as setup Object can kick out the use of @seeAllData=true.

Thanks!!

Flag

Ken Gibson - 7 years ago

Please? This causes headaches for us as well.
- Flag

Baird Straughan - 7 years ago

Absolutely agree. I use custom settings to set things like acceptable donation levels, which are enforced by data validation. If an organization changes its acceptable donation levels, then I have to change the test code - otherwise the validation rules fail the test.

Flag

Kirill Yunussov - 8 years ago

I'm surprised this idea does not have more votes. It's two conflicting best practices.
- Flag
dav condev - 8 years ago

Oops make that MIXED_DML_OPERATION...
- Flag
dav condev - 8 years ago

Also creating custom settings test data can be problematic due to MIXED_DML_EXCEPTION and not being able to call @future methods in test classes
- Flag

Matthew Lamb - 8 years ago

I'd love to see this. Today I ended up creating a single class that instantiates all the custom settings so it's reduced to a single line call, but it would be great if I could remove that from my test framework as it just adds runtime.

Flag

Soporte LeadClic - 8 years ago

I hope they release an upgrade to this soon. I think that SEEALLDATA invalidates the test as you stop having control of many of the operations tested, and asserts turns to be unreliable some times.

The only workaround to not use SeeAllData is to write the Custom Settings objects from CSV stored as Static Resources... still a very twisted way to do it.

Flag

Ideas

Apps

from AppExchange

Questions

No results found.

COVID-19

All Ideas

Idea Details

Latest Comment from Salesforce

Comments ( 18 )

Ideas

Apps

Questions

Links

Salesforce

Need Help?