Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.
Sign up to join this community
I'm trying to create a class that will act like a BaseClass for my Test classes.
It must include several variables, constants and methods common to my test methods.
The kicker is that Test methods are static and we can't inherit static variables/methods from a virtual or abstract class.
Therefore I wonder if you guys have ever had to develop something like that and, if yes, what was your approach to avoid repeating the same constants over and over again into each test class.
Even if the inheritance approach was not blocked by the static method declarations, composition is arguably a better way to go - see e.g.
Composition vs Inheritance and many other discussions.
You can create separate classes that you create and invoke from your static test methods to do various aspects of the work. If these classes are shared between test classes, you can make them top-level classes or if they are relevant to only one test class you can make them nested classes of the test class. These classes can use various designs, from just being simple holders of constants, to patterns such as the builder pattern. Both data setup and assertion methods can be added.
Remember that each test method is isolated from the other test methods: there is no mechanism to communicate values between the methods. So each method needs to setup its own environment.
(The @TestSetup annotation allows some shared data setup to be done but references to that data need to be queried in each test method.)
private constants in the product code you can make them accessible to tests using @TestVisible.
@TestVisible keyword. I was just trying to imagine a way to improve the code accessibility, but it turns out I'm already following the best practices related to it. But thanks you all for your inputs.
Apr 3, 2017 at 12:33