4

I tend to use .getUrl() and .startsWith() e.g. System.assert(nextPage.getUrl().startsWith(Page.ExpectedPage.getUrl()), nextPage.getUrl()); It's good to use startsWith() in case the controller puts parameters on the end.


4

When you compare 2 objects in Salesforce (as far as it is known it is based on Java), it actually compares not objects, but their hashCode results, or what is returned as compareTo method from Comparable interface. Since given class (PageReference) is system, it is impossible to know if two PageReference objects are same - event if those are created from ...


3

You could use getUrl() method to compare the URLs in an assert: System.assertEquals(p.getUrl(), controller.forwardToCustomAuthPage().getUrl()); Also note that the use ofSeeAllData=true in test class is a bad practice.


2

No. A failed assertion is an automatic transaction abortion, just as if you'd violated a governor limit. You cannot try-catch AssertionException; if you must use an exception, throw a custom exception, but be aware that throwing an exception is a costly CPU operation (relatively, anyways), so it should only be used as a last resort.


2

Don't follow the example set by this code. The syntax is system.assertEquals(expected_value, actual_value, message). In the assertions above, expected_value and actual_value are flipped. While the message argument is optional, it is highly recommended and might have helped you here. When using magic numbers in your unit tests, you can give them more ...


2

Not a bug per-se, this is exactly the point of assertNotEquals... if the parameters ARE NOT EQUAL it returns true. Else, it returns false. You answered yourself in your question: "Both the values will be same, the assertNotEqual is failing because both the values are same!" Exactly right, as it should. See the docs for more information: https://...


2

No, they won't be adjusted or removed from your code. You need to handle them. And if due to data or any other condition if the assert didn't match then your end user will get an exception as well. You should use comments for the documentation purpose if that's your goal. You can update your comments with date to mention all the changes which you have done ...


1

No, AssertException is not catchable and should never be used in production code. If you need to throw an exception in your code, define a custom exception type: class MyException extends Exception { } ... if (/*errorCondition*/) throw new MyException('error message'); And you can actually now throw standard exception types as well, so you could forego ...


Only top voted, non community-wiki answers of a minimum length are eligible