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
astroboiiiastroboiii 

DescribeFieldResult isNillable is a LIAR! - returns 'true' for Account.Name field

I'm tryign to help aid some developers on their test class creation in an environment with a lot of cooks in the kitchen.  Things are changing quite often and it's often hard on the test case creation process when fields that weren't required yesterday are required tomorrow etc.

 

So I'm trying to make a simple class that takes in an object type and builds the object for you, checking the objects describe field results to find the fields required.

 

However, in trying to do this one of the parameters I use is checking if the field's isNillable is false.  This worked for some environments but not in others... For example, in one environment account.name was returning a true value for IsNillable but we all know this is not true (and after thinking I lost my mind and tried to do this myself on the backend as a test...I confirmed you can't).

 

Any ideas why it would return true? or does anyone have a sure fire way to detect which fields are required using the schema?

 

Thanks

steve456steve456

You need to keep updating the test class inorder to satisfy the new validation rules and giving data for  requred fields.There is no way to get out of it inorder to deploy your stuff in production

astroboiiiastroboiii

Hi Steve,

 

Thanks for replying.  I understand that there will still need to be some ownership on the developer writing the test class to fully flesh out what fields need to be populated to support their tests.  However, this would overcome the hurdle with being able to cover at least fields which are required populated as a base so as to ensure developers are not missing any of these fields (which are constantly in flux) when writing the test class.

 

It let's them worry about the test scenario and not external config. changes.  We've had many issues with deployments where test classes which were fine one day were broken the next simply because of a new required field which wasn't required yesterday.

 

Hopefully that makes it clearer.

 

 

Still no idea why the isNillable is returning true, is this a legitimate bug in the schema?

SuperfellSuperfell

At a guess this may depend on if you have person accounts enabled or not.

astroboiiiastroboiii

Hi Simon,

 

I was testing exactly this scenario earlier today and I believe it to be true.  Any idea if this is only true with the Account object? or can it act odd with other sobjects as well?

 

Seems like this may not be possible without manually working around the person account issue.

 

Thanks

steve456steve456

Could you run the test and paste the error  you are getting.

 

Also make sure you give a copy of the debug logs so as to know wat is happening exactly

astroboiiiastroboiii

It's not so much that i'm getting an error as much as the Name field on the Account is not being returned as required.  Although to Simon's point this is most likely due to us having Person Accounts turned on.  

 

Not sure of a way to distinguish between person accounts and general accounts through the schema without awkwardly handling it through the code.  Also, I wonder if any other similar hiccups exist. 

steve456steve456

It might also a page layout required field and you might also be wrkng with recordtypes in test case.pls chck

astroboiiiastroboiii

account.name is def. a required field at the field level.  And the reason for going to the schema is that only field level changes are respected and not page layout level requirdeness (as far as I understand, since the schema is derived from the sobject.

 

Just to provide some context, the reason for this exercise in the first place was to ensure we have all required fields covered (at the field level) for test classes and then in the test case itself you would fill it out the remaining fields which you would be fullyu aware of as developed it based on the record type you needed to use it for.

Mauricio OliveiraMauricio Oliveira

Hi,

 

I was doing some a similar test and came to the same conclusion that isNillable() does not provide the output I expect. A lot of fields that NEED some value in the interface show up as nillable by DescribeFieldResult.isNillable() method.

 

Why is that happening? Or is there any other way for me to find out if a certain field is required or not?