4

I have an Apex test that is testing if a record is in an approval process.

To test, I have to submit a record for approval - but there is no guarantee that there will be an approval process set up in the Org.

Generally, in test classes, I keep them self contained to generate their own test data, but for metadata, I would have to manually create it through the UI.

I could query existing approval processes, but I feel as though I should create a new, unique and unreachable one just for the purposes of testing - to ensure that if business requirements change then I do not have to worry about my tests.

Is it good practice to create an approval process for the purposes of testing, and by extension to create metadata in general just for testing? How do ISV packages handle this scenario?

(Hopefully, this meets the criteria of a good subjective question)

  • Why do you want to test the approval process if your package does not contain one? Ideally you should test for your own code and metadata, not for the code and metadata in client org – Pranay Jaiswal Jun 17 at 10:35
  • @PranayJaiswal I need to display all records in an approval process. Whether or not it is "my" approval process. Just to be clear though, I'm not developing a package. – scousins Jun 17 at 10:37
  • This test class would only be run during package installs and updates right? – Pranay Jaiswal Jun 17 at 10:39
  • @PranayJaiswal It might not necessarily be a package, but I'd like to hear opinions and experience from both sides if possible. – scousins Jun 17 at 10:46
2

Is it good practice to create an approval process for the purposes of testing and by extension to create metadata in general just for testing?

In my opinion, no, it is not. Creating metadata (I assume you mean creating and packaging or delivering rather than creating in a test context, which is impossible) opens up a wide variety of potential error situations down the road, because it is part of the org metadata. I would be skeptical of the idea of trying to construct metadata that will be guaranteed inert and never interact with anything other than the test class.

Instead, I would prefer to use a dependency injection approach, where in the unit test context all queries (those for specific metadata and those for affected records) are mocked and controlled in the test context, with no exposure to real metadata or real records. The mock queries can be constructed with an eye on a real org that has the metadata present to ensure verisimilitude.

The DI approach is not without risks - if the platform changes in some way that invalidates the mocks, or if they're developed incorrectly, the tests will show a false positive - but in my opinion it is cleaner and probably safer than using real, but test-only, metadata.

(This primarily reflects my experience building end-user and client code, rather than ISV packages).

How do ISV packages handle this scenario?

My experience with ISV packages is limited. I'm interested to see if other ISVs have divergent experience.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.