New Year’s Unit Tests

It’s that time of year when everyone makes resolutions. I’ve never much cared for resolutions. They’re not my thing – too ambiguous. Yet the idea of setting up a goal and working towards it over the course of the next year is a powerful tool for growth. Still, as software developers, we can do better than resolutions. Software developers have a ready-made model for defining expectations and checking them. Unit Tests.

You may be thinking ok, he’s having a (mental) compiler issue. If you think about it they line up well. You may have met a Unit testing advocate that had strong feelings on when you write tests. One of the schools of thought is that you should write your tests first and then write code to make them pass. If we accept that model, a Unit Test is a perfect fit. Writing our tests now allows us to model the behavior we’re hoping for and the steps we’ll take to measure it. Now that I’ve convinced you to write some New Year’s Unit Tests, I thought I’d share a few of mine:

Let’s Code Together!

@isTest // note to self: It's not @testMethod.
private static void pairWithMoreCommunityMembers(){

  List<CodeLiveSession__c> existing = [
    SELECT ID, Name, CommunityPairPartner__c
    FROM CodeLiveSession__c
    WHERE ShowDate__c = THIS_YEAR
  ];

  CodeLive.callForPartners(); // see below.

  Test.startTest();
  CodeLive.withSalesforceDevelopers();
  Test.stopTest();

  List<CodeLiveSession__c> endOfYear = [
    SELECT ID, Name, CommunityPairPartner__c 
    FROM CodeLiveSession__c 
    WHERE ShowDate__c = THIS_YEAR
  ];

  System.assert( existing.size() < endOfYear.size(), 
    'Expected there to be more code live with community partner sessions over the year');
}

This one is pretty straightforward. Over the next year, I want to do more CodeLive sessions. Furthermore, I want to pair with the Salesforce community. Simply put, I want to work on solving interesting problems with you. Which leads me to this: We have an opportunity for you to join us on CodeLive. You can nominate yourself by filling out this form. Why? Well, for one, it let’s you express an interest in pairing with me during a CodeLive session. Don’t get me wrong, I’m ready and willing to voluntold some of you. That said, I want to make sure everyone has an opportunity to express interest. The form also helps us identify what kinds of code and technology you’d like to see explored on CodeLive. Want more Lightning Web Components? How about the Chatter API? Fill out that form, and let us know.

Tune in every Thursday at 10am Pacific time for CodeLive! Starting 2/6/2020

Did you know that starting in February, CodeLive has a standard time slot on Thursdays at 10am Pacific? You can tune in every week on Trailhead Live! Ok, onward and upwards!

Mentorship is more than teaching a skill.

@isTest // note to self: It's not @testMethod.
private static void beAMentor(){

  Test.startTest();
  Self.beAMentor();
  Test.stopTest();

  System.assert(
    [
      SELECT Id FROM MentorshipRecord__c 
      WHERE ActivityDate__c = THIS_YEAR
    ].size() > 2, 
    // Thanks to eagle eyed readers, I've fixed the previously unescaped quote below.
    'Expected to find at least two examples of how I\'ve been a mentor this year.');
}

If you ask 10 developers what ‘being a mentor’ means, you’ll likely get 15 answers. It’s one of those things that’s nebulous at best, but here’s one example I want to do this year to mentor others: be a RAD Women coach.
RAD Women teaches women software development skills on the Salesforce platform.
I’ve been a coach in the past, and it’s always one of the highlights of my week. Seeing the Aha! moments when the pieces click is always awesome. But coaching’s not mentorship, not by itself.

Mentorship is more than teaching a skill. Mentors provide insight, and knowledge. More importantly, they inspire hope, share vulnerability and give encouragement when things don’t go brilliantly. The best part of mentorship is that everyone is always, always equipped to be both mentor and mentee. Rarely are any of us the smartest person in the room, or the least experienced.

We always have something to learn, and something to share.

I want to encourage you to intentionally find a mentor, and to intentionally be a mentor. Meet with them weekly, and work on a skill(s) together. Provide insight, knowledge, hope and vulnerability with your mentee. Listen and ask questions of your mentor. Most importantly, write about what you learned, so that others can learn too!

MyPetProject.start()

@isTest // note to self: It's not @testMethod.
private static void haveAPetProject(){

  FaceDatabase.setup();

  Test.startTest();
  Self.experimentWithAugmentedReality();
  Test.stopTest();

  System.assert(
    [
      SELECT Id 
      FROM AugmentedReality__c 
      WHERE ActivityDate__c = THIS_YEAR
    ].size() > 1, 
    'Expected to find some experimental code for doing Augmented Reality.');

}

I’ve always found augmented reality demos to be fascinating. The recent advancements in Augmented Reality on mobile devices have really impressed me. It has great potential for enriching everyday interactions. Even though I’m fascinated with it, I’m not sure I’ve found a great use case for it. This year, as a ‘pet’ project, I want to identify a great use case and build a demo. This will let me experiment and play with the technology’s limitations and possibilities. Right now, I’m leaning towards an app that superimposes supplemental product information. Imagine with me, an app that lets you see online ratings for a toy while you’re in the store. Or an app that allows you to scan a conference crowd, and see contact information for those who’ve opted in.

I learn best when I’ve got a pet project. It helps me focus my learning to solve a goal by forcing me to think through how X would help or hinder the project. Do you have a pet project? If so, what’re you building for fun and learning in 2020? I used to joke that when we switched to the 30hr day, I’d finally have time for a pet project! Time was my big excuse that prevented me from picking one up. But the truth is, you can make serious progress with 15 minutes a day. I try to write a function, document a feature or map out a data structure everyday over my morning coffee.

What’re you testing for?

Resolutions have always been problematic for me. They’re aspirational statements instead of proper goals. Enter unit tests! These aren’t unit tests to run in your org, but unit tests for your life, your career over the next year. Like resolutions, there’s no right or wrong Unit Tests to write. They’re there to help you be intentional about your day-to-day activities. I’m really curious to see what some of you might write for life Unit Tests, and I hope you’ll share yours on Twitter. Make sure to @mention SalesforceDevs!

In the mean time, if you’d like to learn more about some other important goals, look here. These are the United Nation’s Sustainable Development Goals. What would Unit Tests for these goals look like?