14

I want to follow up a tangent from Ralph's recent question about question quality, regarding questions about unit tests. (This has obviously been an issue for a long time).

We get a lot of unit test questions. We get a lot of low-quality unit test questions, and we get a lot of unit test questions that seem to me to reflect either weakness of available resources, especially at the introductory level, for writing unit tests or poor socialization of those resources.

Let's start identifying the top "buckets" into which these unit test questions fall and build some high quality resources in the form of canonical questions we can use as duplicates for these constant refrains.

If we find some success, I'd love to expand beyond that and build longer-form content and example libraries, too, perhaps in the form of a GitHub repo wiki where we can collaborate - but let's start with some canonical questions and build from there.

I'm going to start an answer here with a few of the key questions that I think are important, and I'll volunteer to write first drafts of at least some of them. Who else wants to collect resources and write standardized answers? What other key points need to be covered in canonical questions? What great answers do we already have on SFSE that we can start from?

For maximum impact, I'm going to suggest that we coordinate releasing a core set of question/answers as a group, using the canonical-qa tag (thanks, @sfdcfox).

11

Here's some buckets of common topics that I think we need to cover. (v.1.1 of this answer).

Note: I've established a GitHub repository to collaborate on initial drafts of canonical questions and answers for this project. I will provide push access to any established StackExchange member who's interested in being part of the first drafting phase. Once we have solid first drafts written, they'll become part of the normal Community Wiki editing process.

How do I start writing my first unit test? / How do I unit test this code? / Will you write my unit test?

These questions come up all the time and I personally would love to have a canonical deflection for them to try to stem downvotes, negative interactions, and frustration for the community (myself included).

A good canonical answer could collect our favorite resources for writing unit tests (How to Write Good Unit Tests, Trailhead, and the Developer Blog's Month of Testing series are among my favorites). It would try to be a succinct clearinghouse of where to go to get started, not a treatise, and would emphasize that most code is not "special" in the sense of requiring unique techniques to test. Lastly, it would mention in passing the importance of assertions and that unit tests are more than a vehicle to obtain code coverage.

How is code coverage obtained and calculated? / How do I increase my coverage? / Why can't I cover these lines?

A good canonical answer to these types of question might both link to the first canonical answer above to surface resources, while emphasizing a few points around coverage:

  • Coverage is a byproduct of writing high quality unit tests.
  • Link to documentation on what lines of code are executable and counted as part of code coverage
  • Briefly summarize common mistakes that cause control structures (loops and condition bodies) not to be covered (mismatched test data).

What should I do if my code uses a callout?

Trailhead has an excellent module on testing callouts using mocks. I'm not sure much more is needed in a canonical answer than to point there.

How do I handle code that cannot be executed in test context?

Summarize situations where one should use Test.isRunningTest() to gate functionality in test context.

Briefly introduce the idea of dependency injection to test behavior of code that uses this type of functionality and link to outside resources.

How does coverage and testing for asynchronous code work?

Briefly summarize and link to documentation regarding the machinery of Test.stopTest() and Test.startTest() as they relate to testing asynchronous code. Summarize issue surrounding testing functionality that could fire multiple batch invocations and multi-level asynchrony (schedulable calls batch, etc), and point towards options for structuring tests for this type of code.

Deployment Errors / Coverage Metrics

Briefly summarize and provide links to documentation to cover issues like:

  • What are the code coverage requirements?
  • How are they applied during a deployment with different test run settings?
  • What are some of the techniques one uses to manage coverage during the deployment process?

Topics Beyond

There's a few really large subject areas that seem to me a little more didactic and somewhat less amenable to covering in a canonical answer. Among them would be topics like

  • How do I write a good unit test?
  • How do I use dependency injection?
  • How do I write a good test data factory?

and so forth. I think we can do a lot of good covering some more bite-sized pieces quickly and providing links to existing resources to address those issues in the mean time, but I'd love for this project to grow to address some of that more long-form content.

  • 3
    I would like to volunteer for this. It will definitely help the newbies here. That being said, some topics according to me should be just kept on Trailhead, – Pranay Jaiswal Nov 28 '18 at 18:48
  • 3
    @PranayJaiswal I definitely agree. We do not want to be duplicative of Trailhead; I think it's best to include Trailhead links alongside other great resources. – David Reed Nov 28 '18 at 18:49
  • 3
    I think for canonical answers, they should give a brief summary followed by a "for more information, see this resource" (some link). Just enough to possibly help super-trivial questions, and a link to a resource for a trivial, but not quite immediately obvious, for more complicated answers. – sfdcfox Nov 28 '18 at 23:58
  • @PranayJaiswal Do you have a GitHub or GitLab account? I'll throw up a repo were we can collaborate on initial drafts and then post then for the community to bang on. – David Reed Dec 2 '18 at 20:58
  • @DavidReed I dm you on twitter. – Pranay Jaiswal Dec 3 '18 at 14:25
  • Thanks, @PranayJaiswal. Anyone else who is interested in collaborating on first drafts, please reach out to me (contact info on my profile) to get repo access. – David Reed Dec 3 '18 at 18:13
  • there's also - when should I use seeAllData=true? and the corollary: "what's wrong with SeeAllData=true" – cropredy Dec 3 '18 at 21:08
  • @cropredy - yes, good point. Are there any situations where that's at all legitimate other than ConnectAPI code? – David Reed Dec 3 '18 at 21:19
  • 1
  • i think there are also some use cases when testing Salesforce2Salesforce where you need SeeAllData=true or testing fieldHistory queries although you can work around most of these with abstraction layers and DI – cropredy Dec 3 '18 at 21:31
  • @cropredy Any interest in writing up a canonical QA with a summary of where to/no to use? – David Reed Dec 4 '18 at 0:52
  • Just an FYI, over the years, how lines of code coverage are calculated has changed several times, especially when it comes to statements that are split into several lines. That actual coverage that's given can depend on how the code is compiled. At one time it depended on the order in which the lines were executed which could cause a single line to not get completely executed and the individual sub lines to count individually as separate line. Very quirky behavior. – crmprogdev Jan 12 at 13:05
3

I've posted the first four canonical Q&As developed as part of this project. You can find them all under canonical-qa.

All of these answers are Community Wikis. If you have other great unit testing resources that belong as part of these community-wide resources, please add them. Let's try to make sure that we provide the most authoritative, comprehensive, and quality resources for users who are learning to write unit tests.

These first four Q&As were written by me (David Reed) and Pranay Jaiswal. I have at least one more to write, and cropredy is planning one on seeAllData=true.

Ideas for more? Let's discuss any other canonical QAs we might need.

Think something is wrong or badly explained? Please fix it! That's the purpose of the community wiki answer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .