function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
debradebra 

Apex Test failure with API version change only?

I am trying to deploy a code update and received test failures on an unrelated test class.
To figure out the issue I did a test where I created a Cset with the original code and validated the class with exact same code as already in production and it validated.
Next all I did was change the API version from 18 to 35 and the validation errors came back.

Has anyone experienced this?  What would be best practice for API versions on Apex.  I figured it would be good to update the API version to current version at the same time as my updated code but this does not seem to be possible.
Best Answer chosen by debra
debradebra
Not 100% clear how this would happen but the unrelated test methods that were faililng during my validation were on an older API version (27).  Turns out these tests were using describe methods which returned some new field data types that were causing the issue - not clear why these tests did not fail when run manually in production????  Anyway the solution was to update these unrelated classes to API version 35 and include them in the Cset (no code changes at all there).

All Answers

pconpcon
This can happen if your test code does not generate all of it's own test data.  Prior to version 32 (I think) your tests would have access to all data in the instance.  After version 32 you can only see data you create inside your test.  There are two ways to approach this.  First, modify your tests to generate all of their own test data.  This is the best and preferred way.  If you absolutely do not have the time, you can add the seeAllData annotation [1] at the top of your test class and it will see all of the data in your org.  I STRONGLY encourage you to NOT use that annotation unless you absolutely have to.  If you don't know why you are using it (after generating your test data in your test class) then don't use it.

[1] https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_seealldata_using.htm
debradebra
pcon - thanks for the inputs.   Here is a bit more detail on my setup/situation.  I am trying to clean-up our test code written by others where in most tests they were using the seeAllData annotation (I agree with you this is not good practice).   So I took one of the test classes and rewrote it to remove SeeAllData this included adding some new methods to a test utility class.  I successfully implemented this and it not only used all it's own test data but the coverage went up too!!  Anyway the 3rd class (which I have not modified yet) is on API 27 and is still using SeeAllData this is the class that is producing the error when I validate my Cset that contains my two improved classes.  I don't want to have to re-write all our test classes at once if I can help it - too much change at once.  Do you have any suggestions how I might get my improved classes to deploy while leaving alone the unchanged older test class which is generating validation errors even when it is not related to the classes I'm trying to deploy?  Do you think the unchanged class would see the test data I'm creating in my updated test class - I thought that test data would only be visible in the class that creates it but perhaps not???
debradebra
BTW - here is the error I am seeing.  Complaining about a unknown field that is actually a standard field.
System.QueryException: No such column 'BillingAddress' on entity 'Quote'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.
debradebra
Found this related issue - older API describe call returning unknown fields but the problem persists even if I update API of the unmodified class..
https://success.salesforce.com/issues_view?id=a1p30000000T0tvAAC
 
pconpcon
Your test classes should run seperately (however methods inside the same class can have some wonkiness with not being able to lock rows) and when running via a change set, they should run in series not in parrallel.  When you update your test code, are you updating the API version of both the test class as well as the trigger/class that you are testing?  Are you getting the QueryException from the test class or from the trigger/class you are testing?  What is the contents of your change set?
debradebra
Not 100% clear how this would happen but the unrelated test methods that were faililng during my validation were on an older API version (27).  Turns out these tests were using describe methods which returned some new field data types that were causing the issue - not clear why these tests did not fail when run manually in production????  Anyway the solution was to update these unrelated classes to API version 35 and include them in the Cset (no code changes at all there).
This was selected as the best answer