DEV Community: Salesforce Engineering

Using Testify Mock in web clients

Andy Haskell — Mon, 24 Oct 2022 14:08:12 +0000

In the last tutorial, we looked at:

How Testify Mock helps us make nondeterministic code testable
How to implement an interface using an embedded Testify Mock
What the general flow of a Testify Mock test looks like

We demonstrated that on random numbers first, since that's the simplest nondeterministic code to be working with.

However, the use case of Testify Mock that ultimately got me learning about that package, was to use it in code that builds on top of clients to web APIs.

The reason code using web API clients is nondeterministic to test is, you don't have total control over what you get back from a web server for a given input, for reasons such as:

✍️ The data you get back for a given server endpoint might change, either slightly or dramatically.
🚧 The server might be down altogether.
🐆 You might be being rate-limited from sending too many requests to the server.
🐛 You'll want test coverage so that your code does the right thing if the server you're talking to is giving back 500s. But since a 500 by definition is an internal server error, it's not necessarily possible to reliably get 500s, especially in the long term.

So for tests where you want the same output every time you run the same API client call in your test, that's a great use case for Testify Mock. So for this tutorial, we'll see how Testify Mock can be used as one of your tools to write test coverage when your Go code's got some Internet to do!

📚 Setting up a fake API to test against

The code we're going to test uses a client for an API that the zoo set up to give facts about animals.

The endpoint our code will be talking to is GET /animal-facts?species={species}&page-token={page-token}, and it returns a JSON object containing a page worth of animal facts, plus a token if there's another page.

If you're following along, copy the code ahead into a file named something like client.go. The main takeaway is that we have a ZooHTTPClient for talking to the zoo's API, and we call the /animal-facts endpoint with the method ListAnimalFacts()

package main

import (
    "fmt"
    "net/http"
)

type ZooHTTPClient struct {
    baseURL string
    client *http.Client
}

// Serialization of error response from zoo API service
type ErrorResponse struct {
    StatusCode int    `json:"status_code"`
    Message    string `json:"message"`
}

func (res *ErrorResponse) Error() string {
    return fmt.Sprintf("got %d error: %s", res.StatusCode, res.Message)
}

type AnimalFactsQuery struct {
    AnimalName string
    PageToken  string
}

func (c *ZooHTTPClient) ListAnimalFacts(q AnimalFactsQuery) (*AnimalFactsResponse, error) {
    // HTTP implementation here; returns an
    // AnimalFactsResponse if the HTTP request succeeds,
    // or an error, of type ErrorResponse, if the request
    // gets a non-2xx HTTP status code.

    // returning nil, nil just so the code compiles
    return nil, nil
}

type AnimalFactsResponse struct {
    Facts         []string `json:"facts"`
    AreThereMore  bool     `json:"are_there_more"`
    NextPageToken string   `json:"next_page_token"`
}

And here is the code we want to test, which we'll copy to a file like main.go. In that code we pass the API client into getSlothsFavoriteSnack so we know what snack to donate a whole bunch of to the zoo. The function returns that snack as a string on success, or if that's not mentioned in any of the facts from the API, then we return errFactNotFound and dust off that library card in order to find that information.

⚠️ NOTE: There is a bug in this code. Don't spend a bunch of time looking for it now, though, we'll fix it when we find that bug using our tests!

package main

import (
    "errors"
    "regexp"
)

var errFactNotFound = errors.New("fact not found")

var favSnackMatcher = regexp.MustCompile(
    "favorite snack is (.*)",
)

func getSlothsFavoriteSnack(c *ZooHTTPClient) (string, error) {
    // Until we're at the last page of facts, call ListAnimalFacts
    // with the current page token to paginate through the list,
    // exiting when either the response's AreThereMore field is
    // false, or we find out what sloths' favorite snack is.
    var pageToken string
    for {
        res, err := c.ListAnimalFacts(AnimalFactsQuery{
            AnimalName: "sloth",
            PageToken:  pageToken,
        })
        if err != nil {
            return "", err
        }

        // check if any facts match the "favorite snack is"
        // regex and if so, return the match
        for _, f := range res.Facts {
            match := favSnackMatcher.FindStringSubmatch(f)
            if len(match) < 2 {
                continue
            }
            return match[1], nil
        }

        // check the response to see if there are any more
        // pages of facts about sloths
        pageToken = res.NextPageToken
    }

    // otherwise if the fact about sloths' favorite snack
    // isn't in the zoo API, return errFactNotFound.
    return "", errFactNotFound
}

Since ListAnimalFacts talks to the server for the zoo's API, the code is nondeterministic. So testing it in a repeatable way is a great use case for Testify Mock.

🥸 Basic test with mock

If you recall from the last tutorial, the steps to doing a test with Testify Mock are:

Take the nondeterministic piece of functionality and wrap it in a Go interface type.
Write an implementation of the interface that uses Testify Mock.
In the tests, use the mock implementation to select deterministic results of the functions your interface calls.

So to start, let's make an interface for our API client.

Wrapping our client in an interface

type ZooClient interface {
    ListAnimalFacts(q AnimalFactsQuery) (*AnimalFactsResponse, error)
}

If we had additional client methods used in our code, such as for other endpoints on the API, we would also add those methods to the ZooClient type as well, but for this tutorial we're only testing code that uses ListAnimalFacts.

Now, to enable using a mock in getSlothsFavoriteSnack, we change that function's signature to take in a ZooClient rather than a *ZooHTTPClient.

- func getSlothsFavoriteSnack(c *ZooHTTPClient) (string, error) {
+ func getSlothsFavoriteSnack(c ZooClient) (string, error) {

Writing a mock implementation of our client

And now just like with the random number generator in the last tutorial, we can use the mock.Mock type to write a mock implementation of our client.

package main

import (
    "github.com/stretchr/testify/mock"
)

type mockClient struct { mock.Mock }

func newMockClient() *mockClient { return &mockClient{} }

func (c *mockClient) ListAnimalFacts(
    q AnimalFactsQuery,
) (*AnimalFactsResponse, error) {
    args := c.Called(q)
    if args.Get(0) == nil {
        return nil, args.Error(1)
    }
    return args.Get(0).(*AnimalFactsResponse), args.Error(1)
}

Just like in the last tutorial, we start by making a mock client that embeds a mock.Mock object, and we retrieve the return values we assigned to the passed-in parameters using Mock.Called.

Unlike in the random number generator example, though, the object we're returning is an *AnimalFactsResponse rather than a primitive Go type like an int. So to get our response as the type we want, we call args.Get(0) which returns an interface{}/any that we then can convert to the type we want with .(*AnimalFactsResponse).

Using our client in a test

Now, let's use our client in a test!

import (
    "testing"
)

var firstPageAPIReq = AnimalFactsQuery{
    AnimalName: "sloth",
    PageToken:  "",
}

func TestGetSlothsFavoriteSnack(t *testing.T) {
    c := newMockClient()
    c.On(
        "ListAnimalFacts", firstPageAPIReq,
    ).Return(&AnimalFactsResponse{
        Facts: []string{
            "Sloths' slowness is actually used as a form of camouflage",
            "Baby sloths make the cutest li'l squeak 🥰",
            "Sloths' favorite snack is hibiscus flowers",
        },
        AreThereMore: false,
        NextPageToken: "",
    }, nil)

    favSnack, err := getSlothsFavoriteSnack(c)
    if err != nil {
        t.Fatalf("got error getting sloths' favorite snack: %v", err)
    }

    if favSnack != "hibiscus flowers" {
        t.Errorf(
            "expected favorite snack to be hibiscus flowers, got %s",
            favSnack,
        )
    }
}

First, we pass in the AnimalFactsQuery we're going to use to c.On() and assign it a mock API response with c.Return().

Now our mock client is ready to use; we call getSlothsFavoriteSnack, and it uses our mock client; when it calls ZooClient.ListAnimalFacts, it gets back our API response, loops through the Facts in the API response, and when it reaches the one titled Sloths' favorite snack is hibiscus flowers, that matches the regular expression, so getSlothsFavoriteSnack returns "hibiscus flowers", nil.

Finally, back in our test, we verify that favSnack is hibiscus flowers and err is nil, just like we would if this test was using a client pointed at and authenticated to a real zoo API.

Run the test, and you'll see that it passed and that sloths love hibiscus flowers! 🌺

Just like that, we've got a Go test on what happens when our code gets back a certain response from an API, and we can run it any time we want with the same result from our mock API; if the zoo's real API server is down, then this test will still run successfully since we're not talking to the real API!

Speaking of when the server is down, we don't want to test just the happy path; we should have some test coverage for what happens if we get an error calling getSlothsFavoriteSnack too.

⛔️ Handling error cases

There's a couple error cases from the API we should have test coverage for:

The server is giving back 500's, which as I mentioned at the beginning of this post, is hard to re-create with a real API.
The API doesn't have the animal fact we want.

Testing that our code handles internal server errors correctly

Let's start with testing the 500 internal server error case.

func TestGetSlothsFavoriteSnack500Error(t *testing.T) {
    c := newMockClient()
    c.On("ListAnimalFacts", firstPageAPIReq).Return(
        (*AnimalFactsResponse)(nil), &ErrorResponse{
            StatusCode: 500,
            Message: "server error",
        },
    )

    _, err := getSlothsFavoriteSnack(c)
    if err == nil {
        t.Fatal("got nil error from getSlothsFavoriteSnack")
    }

    errRes, ok := err.(*ErrorResponse)
    if !ok {
        t.Fatalf("expected error to be ErrorResponse, got %T", err)
    }
    if status := errRes.StatusCode; status != 500 {
        t.Errorf("expected 500, got %d status code", status)
    }
}

Like before, we set up a mock response for firstPageAPIReq in c.On().Return(). But this time, rather than passing in a successful response, we pass in a nil AnimalFactsResponse and an ErrorResponse as our error.

Then, we call getSlothsFavoriteSnack and validate that we got an error, it's of type ErrorResponse, and that its status code is 500. So when we run the test, once again it passes.

Testing the error case where the API doesn't have the sloth fact we want

Now that we've got a test for our 500 error, let's test the case where we don't have the sloth fact we want. In that case we expect that getSlothsFavoriteSnack returns errFactNotFound.

func TestGetSlothsFavoriteSnackNotFound(t *testing.T) {
    c := newMockClient()
    c.On(
        "ListAnimalFacts", firstPageAPIReq,
    ).Return(&AnimalFactsResponse{
        Facts: []string{
            "Sloths' slowness is actually used as a form of camouflage",
            "Baby sloths make the cutest li'l squeak 🥰",
            "Sloths need their beauty sleep, plz send noise-cancelling headphones",
        },
        AreThereMore: false,
        NextPageToken: "",
    }, nil)

    if _, err := getSlothsFavoriteSnack(c); err != errFactNotFound {
        t.Fatalf("should have gotten errFactNotFound, got %v", err)
    }
}

We start with a similar test setup to the success case, except this time around, the response we set up doesn't include information about what sloths like to eat. So at the bottom of the test, we assert that the error we get back is errFactNotFound and that we should head to the library.

Run this test though, and you should get an infinite loop; if you wait about 10 minutes the test will fail because getSlothsFavoriteSnack never returns, so the test times out.

In other words, we found a bug in getSlothsFavoriteSnack. If you recall, this was the for loop in there:

for {
    res, err := c.ListAnimalFacts(AnimalFactQuery{
        AnimalName: "sloth",
        PageToken:  pageToken,
    })
    if err != nil {
        return "", err
    }

    for _, f := range res.Facts {
        match := favSnackMatcher.FindStringSubmatch(f)
        if len(match) < 2 {
            continue
        }
        return match[1], nil
    }

    pageToken = res.NextPageToken
}

We use a for loop because this API is paginated so that if there's more than one page worth of sloth facts, we can check the next page. The bug is that we never break out of the for loop if we're at the end of the list of sloth facts, as specified by the AreThereMore field on the response. If you've tricked out your editor, that might have told you that the line returning errFactNotFound was unreachable, and that's why.

So let's fix the bug!

    for _, f := range res.Facts {
        match := favSnackMatcher.FindStringSubmatch(f)
        if len(match) < 2 {
            continue
        }
        return match[1], nil
    }

    pageToken = res.NextPageToken
+   if !res.AreThereMore {
+       break 
+   }

Run the test again and now our test should pass!

📖 Pagination with MatchedBy, Once, and AssertNumberOfCalls

As one last thing to test, since the API is paginated, we also should have some test coverage for when the information about sloths' favorite snack isn't on page 1.

In this API we're mocking, requests and responses include a PageToken/NextPageToken field, to tell the API which page of sloth facts to retrieve. So a test for the scenario where the search results are on the second page might look like this pseudocode:

Add a mock for page 1, where the AnimalName is "sloth" and PageToken is a blank string.
1. Have that mock API call return our search results, AreThereMore=true, and NextPageToken=NEXT.
Add a mock for page 2, where AnimalName is "sloth" and PageToken is "NEXT".
1. Have that mock API call return a second page of search results; AreThereMore=false and page 2 contains the information that sloths love hibiscus flowers.
Run getSlothsFavoriteSnack and check that "hibiscus flowers" is still retrieved.

We could pass each individual query into Mock.On(), and that wouldn't be too difficult to write in this example code. However, if this API was more complicated and we were testing more-complicated fields, it can be a pain to ensure that each call to Mock.On has exactly the right fields on the structs we're passing in. In particular, you might have a more complicated function than getSlothsFavoriteSnack you want to test, where it takes a lot of staring at your code in order to figure out the exact arguments each individual API call has.

In this test we're running, we're not that worried about the exact content of the PageToken field, since API page tokens tend to be pretty opaque. Whether the page token says something like "page 2", "some more facts on the next page", or a UUID. Essentially, we're not the ones who care about the page token's formst; the zoo's API team is in charge of that!

What we're really testing in a TestGetSlothsFavoriteSnackResultIsOnTheSecondPage (that's a mouthful!) test is that if the information we want is on the second page, we're still able to retrieve it with another query for sloth facts. And there's a handful of functions that can help us test that, to a reasonable "just the important stuff" level of detail, which are:

MatchedBy; instead of passing in an argument to Mock.On() that the argument in the test has to exactly match, you pass in a function that defines the criteria for whether an argument in the test matches the argument to Mock.On().
Once; specify arguments and return values with Mock.On().Return() that are only to be called and given back once. For example in a paginated API, the arguments you call in each round of the loop are nearly the same, so you can add Once() on to your mock call to say "give us back each page of results only once".
AssertNumberOfCalls; if the mocked-out code you're testing is called in a loop, this allows us to check that the loop ran the expected number of times.

To try these out, let's give some test coverage where sloths' favorite snack is on page 2.

func reqSlothFacts(q AnimalFactsQuery) bool {
    switch strings.ToLower(q.AnimalName) {
    case "sloth",
        "lemur: caffeine-free edition",
        "descendants of the giants who made today's avocados happen":

        return true
    default:
        return false
    }
}

var page1 = AnimalFactsResponse{
    Facts: []string{
        "Sloths' slowness is actually used as a form of camouflage",
        "Baby sloths make the cutest li'l squeak 🥰",
        "Sloths need their beauty sleep, plz send noise-cancelling headphones",
    },
    AreThereMore: true,
    NextPageToken: "some more facts on the next page",
}

var page2 = AnimalFactsResponse{
    Facts: []string{"Sloths' favorite snack is hibiscus flowers"},
}

func TestGetSlothsFavoriteSnackOnPage2(t *testing.T) {
    c := newMockClient()
    c.On("ListAnimalFacts", mock.MatchedBy(reqSlothFacts)).
        Return(&page1, nil).
        Once()
    c.On("ListAnimalFacts", mock.MatchedBy(reqSlothFacts)).
        Return(&page2, nil).
        Once()

    favSnack, err := getSlothsFavoriteSnack(c)
    if err != nil {
        t.Fatalf("got error getting sloths' favorite snack: %v", err)
    }

    if favSnack != "hibiscus flowers" {
        t.Errorf(
            "expected favorite snack to be hibiscus flowers, got %s",
            favSnack,
        )
    }

    c.AssertNumberOfCalls(t, "ListAnimalFacts", 2)
}

Here's what happens in our test:

Outside of our test, we define the function reqSlothFacts we'll pass into MatchedBy. We match the word "sloth", as well as a couple other ways to describe a sloth just for fun: "lemur: caffeine-free edition" and "descendants of the giants who made today's avocados happen" (giant ground sloths 10,000 years ago ate what avocados looked like 10,000 years ago, so next time you have some guac, thank a sloth). We also define two pages of search results.
Inside our TestGetSlothsFavoriteSnackOnPage2, we define two calls to ListAnimalFacts similar to before, but this time instead of passing in an exact query, we pass in mock.MatchedBy(reqSlothFacts) to say "a call to ListAnimalFacts matches this call to Mock.On() if its argument, passed into reqSlothFacts, returns true".
On each call to Mock.On(), we add on a call to .Once(). When we call getSlothsFavoriteSnack, the first time we get back the results we defined with page1 and the second time we get back the results we defined with page2.
Then we run the test the same way as before, but at the tail end, we run AssertNumberOfCalls to show that we really did call ListAnimalFacts twice, rather than getting the results on the first page.

By the way, in addition to MatchedBy, if you don't need such fine-grained control over the arguments you pass in, there also is mock.Anything that you can pass into Mock.On to match any argument at all.

For example, a lot of API clients these days take in a context.Context, which is often in charge of things like traces with observability tools or giving a request a deadline to finish with context.WithDeadline. But often that does not affect the headers and body of our request or response. So if the context isn't a focal point of what you're testing, you can mock it out with Anything. For example if our client's interface looked like this:

type ZooClient interface {
    ListAnimalFacts(
        ctx context.Context,
        q AnimalFactsQuery,
    ) (*AnimalFactsResponse, error)
}

You would do your Mock.On call like this:

  c := newMockClient()
  c.On(
      "ListAnimalFacts",
+     mock.Anything,
      firstPageAPIReq,
  ).Return(&AnimalFactsResponse{

🧰 Testify Mock is just one tool for testing your web apps

As you can see, Testify Mock is a convenient tool for testing code that needs to make an API call, particularly when it comes to HTTP responses like 500 errors that you're not suppposed to consistently be getting.

But there's another way we could have tested all these API interactions without having to rely on the real API:

Make an httptest.Server that has HTTP handlers to mimic the API endpoints we're testing, deserializing requests and serializing responses
Point the HTTP implementation of the API client at that server and run tests using that implementation
Do assertions on the mock responses you get back

Both the httptest approach and Testify Mock approach are valid ways to test the code. Furthermore, while both kinds of mocks are useful themselves, that's not to say testing against the real API isn't itself beneficial. By testing against the very same servers your code talks to in production, you can sniff out server behaviors your dev team wasn't aware of from just reading the server's API documentation. While this isn't a hard and fast rule, my personal style for when to use which kind of Go test is:

When I'm the one implementing the client to the API I'm working with, I would go with the httptest Server approach for its unit tests. Part of the client's job is to serialize and deserialize Go types, so the thing being tested, so the focal point of the test is that the headers, request, and response bodies are correct.
For code that's built on top of a client, such as getSlothsFavoriteSnack, my go-to is Testify Mock. Either I wrote and unit-tested the HTTP implementation of the client or the open source developer I'm go getting the client from did. So now the focal point of a test is the question "given that the API client works as expected, does my code do the right thing with the response it gets back"?
- However if you got the client as a dependency but it doesn't have test coverage for the API calls you're making, it might still be a good idea to test using the httptest.Server approach if its implementation allows you to point it at a custom httptest Server URL.
Finally, for testing that your app works end-to-end, having your continuous integration platform run a nightly build that runs tests against the real API will help you detect bugs and unexpected behaviors your mocks might not have taken into account.
- ⚠️WARNING⚠️: Chances are, the server you're talking to in this nightly build will need to obtain and use some kind of API key or authentication token. BE CAREFUL configuring your continuous integration so that that authentication doesn't get stolen. In particular, do not put the key/token directly in your code.

Happy testing!

Mocks in Go tests with Testify Mock

Andy Haskell — Mon, 24 Oct 2022 14:07:47 +0000

In parts 1-3 of this tutorial series, we saw how you can use Go to write automated tests. Go's testing is very conducive to giving test coverage to a lot of your codebase's functionality. However, there's one area in particular where it's harder to do automated tests: code that is nondeterministic.

When I say nondeterministic code, I am talking about code where you don't have total control over the code's logic and output. This can be things like:

🧮 Code that uses pseudorandom number generators, like math/rand
💻 Web API calls and their response payloads, or errors
⏰ The current time returned by time.Now

Luckily, one tool that helps with testing nondeterministic code, is the mock package of the popular Testify testing framework, which you can use for mocking out these API calls.

For this tutorial, we'll look at how to mock out code that uses math/rand, then in a follow-up post, we'll mock out a fake web API client to see how to use Testify Mock in more complex scenarios.

Prerequisites for this tutorial are familiarity with the basics of writing and running a Go test, which the first tutorial in this series covers.

🎰 Getting some nondeterministic code and the Testify Mock package

Probably the easiest nondeterministic code to get ahold of is the math/rand package, so for this tutorial, we'll look at how we would use Testify Mock to test code that uses randomness. We'll make a function that takes in an integer, and integer-divides (no decimal point) it by a number between 1 and 10.

package main

import (
    "math/rand"
)

func divByRand(numerator int) int {
    return numerator / int(rand.Intn(10))
}

Pretty simple function, but since we called rand.Intn, which takes in a maximum value and returns a random integer up to that maximum, divByRand as a whole is nondeterministic; we have control over the numerator, but not the denominator.

But that's where Testify Mock package comes in; we can make it so in a given test, we do get back the same value for rand.Intn every time.

First let's install Testify Mock with:

go get github.com/stretchr/testify/mock

Now we're ready to use Testify Mock to give divByRand some test coverage!

✨ Using Testify Mock

Now that we've got our nondeterministic code, here's the steps to making it testable with Testify Mock:

Take the nondeterministic piece of functionality and wrap it in a Go interface type.
Write an implementation of the interface that uses Testify Mock.
In the tests, use the mock implementation to select deterministic results of the functions your interface calls.

Besides injecting your mock into your code, the test is otherwise written like any other Go test.

Let's try it out on divByRand, step by step!

1. Take the nondeterministic function calls and wrap them in an interface

For divByRand, the nondeterministic code we're working with is math/rand's Intn function, which takes in an integer and returns another integer. Here's what wrapping that method in an interface looks like:

type randNumberGenerator interface {
    randomInt(max int) int
}

Now that we've got our interface, here's the plain implementation that calls the standard library's rand.Intn.

// our standard-library implementation is an empty
// struct whose randomInt method calls math/rand.Intn
type standardRand struct{}

func (s standardRand) randomInt(max int) int {
    return rand.Intn(max)
}

Now that we've got one interface implementation, we can use that in our divByRand function like this:

  func divByRand(
      numerator int,
+     r randNumberGenerator,
  ) int {
-     return numerator / rand.Intn(10) 
+     return numerator / r.randomInt(10)
  }

We now would call divByRandom in our production code using a function call like divByRandom(200, standardRand{}).

In tests, though, we will instead use a mock implementation of our randNumberGenerator interface, which we'll write in the next section.

2. Write an implementation of the interface that uses Testify Mock

The Testify Mock package's main type is Mock, which handles the logic for mock API calls, such as:

For each method being mocked, keeping track of how many times it was called, and with what arguments.
Providing the coder with a way to specify return values to get back from the mock implementation when specified arguments are passed into given function calls.

We would first set up our mock implementation by embedding a Mock into a struct:

type mockRand struct { mock.Mock }

func newMockRand() *mockRand { return &mockRand{} }

By embedding a Mock, now the mockRand type has the methods for registering an API call that you expect to happen in the tests.

For example, at the beginning of a test that uses the randomNumberGenerator interface, we could call:

var m mockRand
m.On("randomInt", 10).Return(6)

which says "if the number 10 is passed in as the maximum number for this mockRand's randomInt method, then always return the number 6".

In order to be able to use m.On("randomInt", arg) however, we will need to actually give our mockRand a randomInt method. Here's how we would do that:

func (m *mockRand) randomInt(max int) int {
    args := m.Called(max)
    return args.Int(0)
}

We've got two lines of code, let's take a look at what they do. If it seems confusing at first, no worries; it will make more sense when we are actually using this code in a test.

In the first line when randomInt is called, we call Mock.Called to record that it was called with the value passed in for max.
Additionally, m.Called returns an Arguments object, which contains the return value(s) that we specified in the test to be returned if the function gets the given value of max. For example, if we called m.On("randomInt", 20).Return(7) in the test, m.Called(20) would return an Arguments object holding the return value 7.
Finally, to retrieve the return value, in the second line we call args.Int(0), which means "return the zeroeth return value, and it will be of type int".

Note that in addition to Arguments.Int, there's also Bool, String, and Error methods, which give us back the n-th return value in those types. And if you have a return value of another type, you would retrieve it with the Arguments.Get method, which returns an interface{} you would then convert to the type you expect to get back.

3. In the tests, use the mock implementation and feed in results the function returns.

We've got our mockRand type implementing the randomNumberGenerator interface, so it can be passed into divByRand in Go code, including in our tests. The steps of our test now are:

Create an instance of your mock interface implementation.
Specify what results you want back when the mock's methods are called with a given set of arguments using the On and Return methods.
Run the code that's being tested, the standard way you would in a Go test.
Optionally, use methods like Mock.AssertCalled to check that a given method indeed had been called during the test.

Here's what that looks like in code:

package main

import (
    "testing"
)

func TestDivByRand(t *testing.T) {
    // get our mockRand
    m := newMockRand()
    // specify our return value. Since the code in divByRand
    // passes 10 into randomInt, we pass 10 in as the argument
    // to go with randomInt, and specify that we want the
    // method to return 6.
    m.On("randomInt", 10).Return(6)

    // now run divByRand and assert that we got back the
    // return value we expected, just like in a Go test that
    // doesn't use Testify Mock.
    quotient := divByRand(30, m)
    if quotient != 5 {
        t.Errorf("expected quotient to be 5, got %d", quotient)
    }

    // check that randomInt was called with the number 10;
    // if not then the test fails
    m.AssertCalled(t, "randomInt", 10)
}

Run go test -v and you'll get a passing test. But there's a bug in the original implementation of divByRand, so let's find it and give that bug some test coverage!

🐛 Finding and fixing a bug using Testify Mock

We wrote a test that utilizes Testify Mock, so now let's try using it to find a bug!

Since we're dividing by a nondeterministic value, we should have test coverage to make sure we can't accidentally divide by zero.

func TestDivByRandCantDivideByZero(t *testing.T) {
    m := newMockRand()
    m.On("randomInt", int64(10)).Return(int64(0))

    quotient := divByRand(30, m)
    if quotient != 30 {
        t.Errorf("expected quotient to be 30, got %d", quotient)
    }
}

This time around, when we pass 10 into our mockRand's randomInt method, we return 0. So in divByRand, we end up dividing by 0.

Run go test -v and you should get:

--- FAIL: TestDivByRandCantDivideByZero (0.00s)
panic: runtime error: integer divide by zero [recovered]
    panic: runtime error: integer divide by zero

A panic from dividing by zero. Let's fix divByRand method to prevent this:

  func divByRand(n int, r randNumberGenerator) int {
-     return n / r.randomInt(10)
+     denominator := 1 + int(r.randomInt(10))
+     return n / denominator
  }

Now that we're passing 9 instead of 10 into our call to randomInt, we do need to update our test coverage to register a call to randomInt(9) instead of randomInt(10), and for TestDivByRand, we need to return 5 instead of 6 since in divByRand we add 1 to the returned value.

  func TestDivByRand(t *testing.T) {
      var m mockRand
-     m.On("randomInt", 10).Return(6)
+     m.On("randomInt", 10).Return(5)

Run go test -v one more time and you should get...

=== RUN   TestDivByRand
--- PASS: TestDivByRand (0.00s)
=== RUN   TestDivByRandCantDivideByZero
--- PASS: TestDivByRandCantDivideByZero (0.00s)
PASS
ok      github.com/andyhaskell/testify-mock 0.114s

Passing tests!

We've looked at how to use Testify Mock to write test coverage for randomness. In the next tutorial, we'll take a look at using Testify Mock to mock out a web API call.

Test your Go web apps with httptest

Andy Haskell — Fri, 23 Jul 2021 14:50:05 +0000

In part 1 of this series, we looked at the basics of writing tests in Go with the testing.T type, and in part 2, we looked at how with just the testing.T type, you can organize your tests with its Run, Skip, and Cleanup methods. Even with a good grasp of just testing.T, you're ready to write professional test coverage in your Go codebase.

But testing.T and isn't all that the Go standard library provides for writing Go tests! One of the most popular uses of Go is building the server code for web apps, using its detailed net/http package. So the Go Team provided us with a sweet additional package for testing web apps in addition to the main testing package: net/http/httptest!

In this tutorial we'll look at:

📋 how to test an HTTP handler with httptest
💻 how to use httptest to test against a real server

This tutorial is for you if you're interested in Go web development or do webdev already, you're familiar with the basics of Go testing and structs, and you have some familiarity with the HTTP protocol's concepts of requests, responses, headers. If you've used the net/http package, that will help you follow along, but if you're new to net/http, this tutorial does have an overview of some Go web app concepts.

📶 A quick overview of Go HTTP handlers

If you already are familiar with Go HTTP handlers, feel free to read the code sample and then skip ahead to the next section. If you're new to Go web development or just want a recap, read on!

Let's start with a recap of one of its core concepts: when you get an HTTP request, you process it using a handler.

Handlers look something like the handleSlothfulMessage function in this code sample (if you're following along, save this to a file titled server.go):

package main

import (
    "net/http"
)

func handleSlothfulMessage(w http.ResponseWriter, r *http.Request) {
    w.Header().Add("Content-Type", "application/json")
    w.Write([]byte(`{"message": "Stay slothful!"}`))
}

func appRouter() http.Handler {
    rt := http.NewServeMux()
    rt.HandleFunc("/sloth", handleSlothfulMessage)
    return rt
}

func main() { http.ListenAndServe(":1123", appRouter()) }

All Go HTTP handlers take in an implementation of the ResponseWriter interface, and a Request struct. Those objects have the following responsibilities:

The Request contains the data of the HTTP request that the HTTP client (ex a browser or cURL), sends to your web server, like:
- The URL that was requested, like the path and query parameters.
- Request headers, for example a User-Agent header saying whether the request comes from Firefox, Chrome, a command-line client, or a punched card someone delivered to a card reader.
- The request body for POST and PUT requests.
The ResponseWriter is in charge of formulating the HTTP response, so it handles things like:
- Writing status codes, like 200 for a successful request, or the familiar "404 file not found" websites make corny webpages for.
- Writing Response headers, such as the Content-Type to say what format our response is in, like HTML or JSON.
- Writing the response body, which can be any response format, like an HTML webpage, a JSON object, or picture of a sloth 🌺!

In our handleSlothfulMessage function, we first add a header to indicate that our response is JSON with the line:

w.Header().Add("Content-Type", "application/json")

And then we write out the bytes of a JSON message that has a header saying "Stay slothful!" with the line:

w.Write([]byte(`{"message": "Stay slothful!"}`))

Note that because we didn't call w.WriteHeader to explicitly select a status code for our HTTP response, the response's code will be 200/OK. If we had some kind of error scenario we'd need to handle in one of our web app's handlers, for example issues talking to a database, then in the handler function we might have code like this to give a 500/internal server error response:

if errorScenarioOccurs {
    w.WriteHeader(http.StatusInternalServerError)
    w.Write([]byte(`{"error_message": "description of the error"}`))
    return
}

// rest of HTTP handler

In the appRouter function, we make a router so requests to our /sloth endpoint are handled with the handleSlothfulMessage function:

func appRouter() http.Handler {
    rt := http.NewServeMux()
    rt.HandleFunc("/sloth", handleSlothfulMessage)
    return rt
}

Finally, in the main function, we start an HTTP server on port 1123 with http.ListenAndServe, causing all requests to localhost:1123 to be handled by the HTTP router we made in appRouter.

Now if you start this Go program and then go to localhost:1123/sloth in your browser or send a request to it via a client like cURL or Postman, you can see that we got back a simple JSON object!

📋 Testing your handler with httptest

As you can see, you can start using your HTTP handler in a real web server without a lot of code. When you're running a net/http server with http.ListenAndServe, Go does the work behind the scenes for you of making http.Request and ResponseWriter objects when a request comes in from a client like your browser.

But that does raise the question, where do we get a ResponseWriter and Request in our Go code when we're testing our HTTP handlers inside go test?

Luckily, the standard library has convenient code for testing that in the net/http/httptest package to facilitate writing test coverage for that, with functions and types like:

The NewRequest function for making the *http.Request.
a ResponseRecorder type that both implements the http.ResponseWriter interface and lets you replay the HTTP response.
a Server type for testing Go code that sends HTTP requests by setting up a real HTTP server to send them to.

To see this httptest in action, let's see how we would test handleSlothfulMessage. If you're following along, save this code to server_test.go:

package main

import (
    "net/http"
    "net/http/httptest"
    "strings"
    "testing"
)

func TestHandleSlothfulMessage(t *testing.T) {
    wr := httptest.NewRecorder()
    req := httptest.NewRequest(http.MethodGet, "/sloth", nil)

    handleSlothfulMessage(wr, req)
    if wr.Code != http.StatusOK {
        t.Errorf("got HTTP status code %d, expected 200", wr.Code)
    }

    if !strings.Contains(wr.Body.String(), "Stay slothful!") {
        t.Errorf(
            `response body "%s" does not contain "Stay slothful!"`,
            wr.Body.String(),
        )
    }
}

Run go test -v, and you should see a passing test!

Let's take a look at what happened, and how we're using httptest in our code:

First, there's making the ResponseWriter and Request:

    wr := httptest.NewRecorder()
    req := httptest.NewRequest(http.MethodGet, "/sloth", nil)

We make our net/http ResponseWriter implementation with NewRecorder, and a Request object pointed at our /sloth endpoint using NewRequest.

Then, we run our HTTP handler:

handleSlothfulMessage(wr, req)

Remember that Go HTTP handler functions are just regular old Go functions that happen to take in specialized net/http objects. That means we can run a handler without any actual HTTP server if we have a ResponseWriter and Request to pass into it. So we run our handler by passing wr and req into a call to our handleSlothfulMessage function. Or if we wanted to test our web app's entire router rather than just one endpoint, we could even run appRouter().ServeHTTP(wr, req)!

Then, in the next piece of code, we check out the results of running handleSlothfulMessage:

    if wr.Code != http.StatusOK {
        t.Errorf("got HTTP status code %d, expected 200", wr.Code)
    }

An httptest ResponseRecorder implements the ResponseWriter interface, but that's not all it gives us! It also has struct fields we can use for examining the response we get back from our HTTP request. One of them is Code; we expect our response to be a 200, so we have an assertion comparing our status code to http.StatusOK.

Additionally, a ResponseRecorder makes it easy to look at the body of our response. It gives us a bytes.Buffer field titled Body that recorded the bytes of the response body. So we can test that our HTTP response contains the string "Stay slothful!", having our test fail if it does not.

    if !strings.Contains(wr.Body.String(), "Stay slothful!") {
        t.Errorf(
            `response body "%s" does not contain "Stay slothful!"`,
            wr.Body.String(),
        )
    }

By the way, this technique also works with POST requests. If we had an endpoint that took in a POST request with an encoded JSON body, then sending the request in the test for that endpoint would look something like this:

var b bytes.Buffer
err := json.NewEncoder(b).Encode(objectToSerializeToJSON)
if err != nil {
    t.Fatal(err)
}

wr := httptest.NewRecorder()
req := httptest.NewRequest(http.MethodPost, "/post-endpoint", b)
handlePostEndpointRequest(wr, req)

First we set up a bytes.Buffer to use as our POST request's body. This is because a net/http Request's body needs to be an implementation of the io.Reader interface. bytes.Buffer conveniently has the Read method, so it implements that interface. We then use json.NewEncoder(b).Encode to convert a Go struct into bytes of JSON that get stored in the buffer.

We make our POST request by passing MethodPost, rather than MethodGet, into httptest.NewRequest. Our bytes.Buffer is passed in as the last argument to NewRequest as the request body. Finally, just like before, we call our HTTP request handler using our ResponseRecorder and Request.

💻 The httptest server

Not only does httptest provide us a way to test our handlers with requests and responses, it even provides ways to test your code with a real HTTP server!

A couple scenarios where this is useful are:

When you're doing functional tests or integration tests for a web app. For example, testing that communication goes as expected between different microservices.
If you are implementing clients to other web servers, you can define an httptest server giving back a response in order to test that your client can handle both sending the correct request and processing the server's response correctly.

Let's try out the latter of these scenarios, by making a client struct to send an HTTP request to our /sloth endpoint, and deserialize the response into a struct.

First, import fmt and encoding/json (and net/http if you're putting the client code in its own file) and then write this code for the client. If you're newer to JSON deserialization, no worries if the code doesn't click 100% for you. The main things you need to know are:

The client we're making has a GetSlothfulMessage that sends an HTTP request to the /sloth of its baseURL.
Using Go's awesome encoding/json package, the HTTP response body is converted to a SlothfulMessage struct, which is returned if the request and JSON deserialization are successful. We are using json.NewDecoder(res.Body).Decode for reading the response body into our SlothfulMessage struct.
If we get a non-200 HTTP status code sending the request, or there's a problem deserializing the JSON response, then GetSlothfulMessage instead returns an error.

type Client struct {
    httpClient *http.Client
    baseURL string
}

type SlothfulMessage struct {
    Message string `json:"message"`
}

func NewClient(httpClient *http.Client, baseURL string) Client {
    return Client{
        httpClient: httpClient,
        baseURL:    baseURL,
    }
}

func (c *Client) GetSlothfulMessage() (*SlothfulMessage, error) {
    res, err := c.httpClient.Get(c.baseURL + "/sloths")
    if err != nil {
        return nil, err
    }

    if res.StatusCode != http.StatusOK {
        return nil, fmt.Errorf(
            "got status code %d", res.StatusCode,
        )
    }

    var m SlothfulMessage
    if err := json.NewDecoder(res.Body).Decode(&m); err != nil {
        return nil, err
    }
    return &m, nil
}

We've got our client, so let's see how we can test it with an httptest.Server:

func TestGetSlothfulMessage(t *testing.T) {
    router := http.NewServeMux()
    router.HandleFunc("/sloth", handleSlothfulMessage)

    svr := httptest.NewServer(router)
    defer svr.Close()

    c := NewClient(http.DefaultClient, svr.URL)
    m, err := c.GetSlothfulMessage()
    if err != nil {
        t.Fatalf("error in GetSlothfulMessage: %v", err)
    }
    if m.Message != "Stay slothful!" {
        t.Errorf(
            `message %s should contain string "Sloth"`,
            m.Message,
        )
    }
}

Here's what happens:

First, we start our server:

    svr := httptest.NewServer(appRouter())
    defer svr.Close()

We pass in our web app's HTTP router as a request handler for the server. When we run NewServer, a server is set up to run on your localhost, on a randomized port. In fact, if you had your test run time.Sleep to pause for a while, you could actually go to that server in your own browser!

Now that we've got our server, we set up our client and have it test an HTTP roundtrip to our /sloth endpoint:

    c := NewClient(http.DefaultClient, svr.URL)
    m, err := c.GetSlothfulMessage()

The base URL we give to the Client, is the URL of the server, which is the randomized port I mentioned earlier. So a request might go out to somewhere like "localhost:1123/sloths", or "localhost:5813/sloths". It all depends on which port httptest.NewServer picks!

Finally, we check that we didn't get an error, and that the response is what we expected. If we run go test -v, we'll get:

=== RUN   TestHandleSlothfulMessage
-------- PASS: TestHandleSlothfulMessage (0.00s)
=== RUN   TestGetSlothfulMessage
    webapp_test.go:37: error in GetSlothfulMessage: got status code 404
-------- FAIL: TestGetSlothfulMessage (0.00s)

A failing test, because we got a 404 response, not the 200 we expected. So that means there's a bug in our client.

The part of GetSlothfulMessage that was for sending our HTTP request was:

func (c *Client) GetSlothfulMessage() (*SlothfulMessage, error) {
    res, err := c.httpClient.Get(c.baseURL + "/sloths")
    if err != nil {
        return nil, err
    }

As you can see, we're sending the request to c.baseURL + "/sloths". We wanted to send it to /sloth, not /sloths. So fix that code, run go test -v, and now...

=== RUN   TestHandleSlothfulMessage
-------- PASS: TestHandleSlothfulMessage (0.00s)
=== RUN   TestGetSlothfulMessage
-------- PASS: TestGetSlothfulMessage (0.00s)

Your test should pass!

As you can see, with the httptest package's ResponseRecorder and Server objects, we've got the ability to take the concepts we were already working with for writing tests using the testing package, and then start using functionality to test both receiving and sending HTTP requests. Definitely a must-know package in a Go web developer's toolbelt!

Thank you to my coworker Aaron Taylor for peer-reviewing this blog post!

Subtesting, skipping, and cleanup in the Go testing.T

Andy Haskell — Mon, 07 Jun 2021 16:00:05 +0000

In my last tutorial, we looked at the basics of writing tests in Go. We saw:

🚦 how the testing.T type is used in all Go tests for managing the status of whether or not a Go test passed
🐛 how we can use tests to catch a bug and fix our code to make a test pass
🗄 how we can use table-testing in order to run tests cases with the same logic together

These are a good foundation to writing test coverage in Go, since any Go repository doing automated tests uses the standard library's testing package, and use the testing.T type. But that's not all the tricks testing.T has up its sleeve!

In this tutorial, we'll look at how we can use three more methods in the testing.T type in order to better organize your tests.

💨 t.Run to give your test cases subtests
⏭ t.Skip, for when we only want to run a test sometimes
🧹 t.Cleanup, for cleaning up state in between tests

And when your tests are well-organized, that improves the quality of life for your dev team when it comes to knowing where to write your tests, and knowing how to fix a failing test. So let's dive in!

💨 Writing subtests for our Go tests

As a quick recap, in the last tutorial, we wrote test coverage for a function telling us whether a string IsSlothful, which returns true if either it contains the word sloth, or it contains the hibiscus emoji but not the race car emoji.

To make it easier to table-test that function, we made this assertion helper function, which has our testing.T run its Errorf method, causing the test to fail, if IsSlothful doesn't return the expected value for the string we're testing:

func assertIsSlothful(t *testing.T, s string, expected bool) {
    if IsSlothful(s) != expected {
        if expected {
            t.Errorf("%s is supposed to be slothful", s)
        } else {
            t.Errorf("%s is not supposed to be slothful", s)
        }
    }
}

And we ran assertIsSlothful in a loop on a slice of different test cases, like this:

type isSlothfulTestCase struct {
    str      string
    expected bool
}

var isSlothfulTestCases = []isSlothfulTestCase{
    {str: "hello, world!",                               expected: false},
    {str: "hello, slothful world!",                      expected: true},
    {str: "Sloths rule!",                                expected: true},
    {str: "Nothing like an iced hibiscus tea! 🌺",       expected: true},
    {str: "Get your 🌺 flowers! They're going fast! 🏎️", expected: false},
}

func TestIsSlothful(t *testing.T) {
    for _, c := range isSlothfulTestCases {
        assertIsSlothful(t, c.str, c.expected)
    }
}

If one of the tests errors, then we get an error message about why the string isn't slothful. Say that we forgot to make checking for the word "sloth" case-insensitive. The error we get would look like this:

-------- FAIL: TestIsSlothful (0.00s)
    sloths_test.go:12: Sloths rule! is supposed to be slothful

We have the descriptive error message of which string we expect to be slothful. But what if our IsSlothful function got a lot more complex, to capture the many nuances of laziness? It would be nice to have a better description of exactly what part of our functionality is being tested. And if we have hundreds of strings we want to test, it would be nice to zoom in on just one, or a few, test cases.

That's where you can subtesting can help you. Since Go 1.7, if inside your Go test, you run the t.Run(string, func(*testing.T)) method, your testing.T will make a subtest within your test.

To try it out, first let's take our isSlothfulTestCase and give it a new string field called testName, which is intended to be a brief description of what we're testing in each scenario. Then, let's add the testName to each of our test cases:

var isSlothfulTestCases = []isSlothfulTestCase{{
    testName: "string with nothing slothful isn't slothful",
    str:      "hello, world!",
    expected: false,
}, {
    testName: `string with the substring "sloth" is slothful`,
    str:      "hello, slothful world!",
    expected: true,
}, {
    testName: `checking for the word "sloth" is case-insensitive`,
    str:      "Sloths rule!",
    expected: true,
}, {
    testName: "strings with the 🌺 emoji are normally slothful",
    str:      "Nothing like an iced hibiscus tea! 🧊🌺",
    expected: true,
}, {
    testName: "the 🏎️ emoji negates the 🌺 emoji's slothfulness",
    str:      "Get your 🌺 flowers! They're going fast! 🏎️",
    expected: false,
}}

Now, let's update our main TestIsSlothful testing loop to use subtesting:

  func TestIsSlothful(t *testing.T) {
      for _, c := range isSlothfulTestCases {
-         assertIsSlothful(t, c.str, c.expected)
+         t.Run(c.testName, func(t *testing.T) {
+             assertIsSlothful(t, c.str, c.expected)
+         })
      }
  }

t.Run takes in two arguments:

The name of our subtest, which will be the description we just added in the testName field
A func(t *testing.T) containing the code we want to run in the subtest. In this case, we are having the subtest just wrap the call to assertIsSlothful.

Now if we run go test -v, the output looks like this:

$ go test -v
=== RUN   TestIsSlothful
=== RUN   TestIsSlothful/string_with_nothing_slothful_isn't_slothful
=== RUN   TestIsSlothful/string_with_the_substring_"sloth"_is_slothful
=== RUN   TestIsSlothful/checking_for_the_word_"sloth"_is_case-insensitive
    sloths_test.go:12: Sloths rule! is supposed to be slothful
=== RUN   TestIsSlothful/strings_with_the_🌺_emoji_are_normally_slothful
=== RUN   TestIsSlothful/the_🏎️_emoji_negates_the_🌺_emoji's_slothfulness
-------- FAIL: TestIsSlothful (0.00s)
    --- PASS: TestIsSlothful/string_with_nothing_slothful_isn't_slothful (0.00s)
    --- PASS: TestIsSlothful/string_with_the_substring_"sloth"_is_slothful (0.00s)
    --- FAIL: TestIsSlothful/checking_for_the_word_"sloth"_is_case-insensitive (0.00s)
    --- PASS: TestIsSlothful/strings_with_the_🌺_emoji_are_normally_slothful (0.00s)
    --- PASS: TestIsSlothful/the_🏎️_emoji_negates_the_🌺_emoji's_slothfulness (0.00s)

We log output for each individual subtest now, rather than only seeing output for scenarios where the test failed. And now we see we got a failing subtest named TestIsSlothful/checking_for_the_word_"sloth"_is_case-insensitive.

The slash in the name is used to indicate that a test being run is a subtest. And in addition to giving a name to the part of our top-level test that failed, you can even use a subtest as input to the -run flag in the go test command. If we have a whole lot of subtests and you want to zoom in on just one test case, like testing that checking for the word "sloth" is case-insensitive, you can run a command like go test -v -run TestIsSlothful/case-insensitve, and the output will look like this:

$ go test -v -run "TestIsSlothful/case-insensitive"
=== RUN   TestIsSlothful
=== RUN   TestIsSlothful/checking_for_the_word_"sloth"_is_case-insensitive
    sloths_test.go:12: Sloths rule! is supposed to be slothful
-------- FAIL: TestIsSlothful (0.00s)
    --- FAIL: TestIsSlothful/checking_for_the_word_"sloth"_is_case-insensitive (0.00s)

Now, we run TestIsSlothful like before, but we skip all of its subtests that don't match the name "case-insensitive"!

⏭ Skipping tests with t.Skip

One of the main benefits to writing automated tests is that you can do things like integrate them into continuous integration (CI) platforms, and you can then have rules on your team like that you only can merge changes if all of the test cases pass. Rules like that can help limit bringing in code that inadvertently breaks functionality because of unforeseen interactions between parts of the code.

But you might have some complex tests that take a really long time to run, or that rely on external services where the test would fail if say, a service your code talks to is unavailable. Especially in the latter scenario, you don't want a different service's outage to bring your team's development work to a halt.

You still want to run those more complex tests, but maybe only once in a while, rather than requiring the test to pass if you want to to bring in a code change. Luckily, there is a convenient workaround for this scenario: the t.Skip method!

To try it out, let's say we have a test for code to automate a quadcopter for feeding the lizards at a terrarium.

func TestQuadcopterDelivery(t *testing.T) {
    q := ConnectToQuadcopter("quadcopter-communication-info")
    if err := q.DeliverFood(
        "from-my-desk", "to-terrarium",
    ); err != nil {
        t.Errorf("error delivering food: %v", err)
    }
}

We could run this every time we do a CI test for a pull request, but that could fail if:

The quadcopter is out of batteries
The quadcopter isn't turned on
Your friend is borrowing the quadcopter
Someone bumped into the quadcopter
The lizards aren't hungry

So the test can't reliably pass every time we push some code.

But let's say we tried running it at a set time where we know the quadcopter is there and charged, no one's gonna get in the way, and the lizards want a snack. Running a build at a certain time is called a nightly build, and you might specify you're in a nightly build with something like whether a given environment variable is present, like NIGHTLY_BUILD, or more accurately in this case, SNACKTIME_BUILD.

To only run TestQuadcopterDelivery only in a nightly build, we could modify the code like this:

  func TestQuadcopterDelivery(t *testing.T) {
+     if _, ok := os.LookupEnv("SNACKTIME_BUILD"); !ok {
+         t.Skip("only running this test on snack build")
+     }
+ 
      q := ConnectToQuadcopter("quadcopter-communication-info")
      if err := q.DeliverFood(
          "from-my-desk", "to-terrarium",
      ); err != nil {
          t.Errorf("error delivering food: %v", err)
      }
  }

We check whether the SNACKTIME_BUILD environment variable is present with os.LookupEnv. If it returns false, we run t.Skip and leave the message that we're only running that test case in a snack-time build. Otherwise, we run the test.

So in our CI configuration for regular builds, we don't set that environment variable. But in our CI configuration for snack-time builds, we would set the variable. Now your dev team can efficiently build next-generation lizard-feeding! 🦎

🧹 Cleaning up after your test

Finally, when you're writing more complicated tests, sometimes there are changes a test has to run that aren't totally contained in the test. Like changes to files, or putting data into databases. This can cause trouble when you're re-running a test, or running a test that uses a system that a different test had changed.

There are different ways of addressing that, like per-test-case namespacing for your data, or mock systems like Afero memory filesystems, and cleaning up after each test case.

For the latter of those, you can use things like Testify Suite to handle cleanups, but since Go 1.14, the standard-library testing.T type now has this new method:

func (t *T) Cleanup(func())

Now when we write a test, we can specify a function that should run at the end of a test. Say we have a function that appends the gopher 🐹 (actually a hamster) emoji to a file:

func addGopher(filepath string) error {
    f, err := os.OpenFile(filepath, os.O_APPEND|os.O_WRONLY, 0644)
    if err != nil {
        return err
    }
    defer f.Close()

    _, err = f.Write([]byte("🐹"))
    return err
}

We might test that like this:

func TestAddGopher(t *testing.T) {
    // set up file to add a gopher to
    path := filepath.Join("test-files", "gopher-added.txt")
    f, err := os.Create(path)
    if err != nil {
        t.Fatal(err)
    }

    if _, err := f.WriteString("Go is awesome!"); err != nil {
        t.Fatal(err)
    }
    f.Close()

    // run addGopher and test that we now have a gopher emoji
    if err := addGopher(path); err != nil {
        t.Fatal(err)
    }

    fileContents, err := os.ReadFile(path)
    if err != nil {
        t.Fatal(err)
    }
    if string(fileContents) != "Go is awesome!🐹" {
        t.Errorf(
            `unexpected file contents %s`, string(fileContents),
        )
    }
}

We create a file at ./test-files/gopher-added.txt, write "Go is awesome!", use addGopher to add the gopher emoji, and then check that the file now has the emoji.

The test is correct, but what if a different test we ran later expected that there were no files in the test-files directory? That test would now fail without any of our code actually being broken, and when that happens, it can be a real pain.

That's where cleanup after a test comes in. Let's give it a try:

  func TestAddGopher(t *testing.T) {
      path := filepath.Join("test-files", "gopher-added.txt")
      f, err := os.CreateFile(path)
      if err != nil {
          t.Fatal(err)
      }

+     t.Cleanup(func() {
+         if err != os.Remove(path) {
+             t.Fatalf("error cleaning up %s: %v", path, err)
+         }
+     })

Now, at the end of TestAddGopher, we run our function to delete test-files/gopher-added.txt. Now our other tests can run without having to worry about any data left over from TestAddGopher!

While that was just a contrived example, cleanup is important in a lot of complex tests working with interdependent systems. If you're coming from using testing systems like Jest in JavaScript, you can use t.Cleanup in scenarios similar to where you would use the Jest afterAll function; the Cleanup function runs after a test and all its subtests complete.

As you can see, in addition to keeping track of the state of tests, the testing.T type gives some great functionality for keeping your automated Go tests well-organized, and you can use that alongside techniques like table testing and CI build system setups.

In my next tutorial on Go testing, we'll look at a different package in the standard library that will come in handy if you're a web developer like me: net/http/httptest!

I Used To Be Human: A Review of Digital Minimalism

Logan Smith — Wed, 26 May 2021 16:13:14 +0000

There was a time, not too long ago, when social media promised freedom from boredom, more robust community, greater efficiencies, and access to networks. However, these promises have come at the cost of our humanity. The addictive overuse of social media has led, as author and computer science professor Cal Newport argues, to increased anxiety, less focused productive work, and a decrease in meaningful relationships. These pressures have been amplified, no doubt, by the Covid-19 driven increase in remote work and the associated screen fatigue.

In his book Digital Minimalism: Choosing a Focused Life in a Noisy World, Newport articulates his case for a life focused on deep value-add activities and reducing time spent in the “attention economy” or, as the title suggests, becoming a digital minimalist. This practice is sorely needed and especially timely in a post-pandemic world as we slowly emerge from our homes and reconnect with the people we’ve only seen via screens for the last year.

Newport is an associate processor of computer science at Georgetown University and has authored several books, including Deep Work and A World Without Email. He is something of a tech-savvy and pop-culture Wendell Berry-lite for the 21st century as he encourages a distracted and anxious generation to stabilize around values of greater importance than the next trending hashtag. In Digital Minimalism, he successfully describes and defends this philosophy that prioritizes long-term meaning over short-term satisfaction and does so in two sections of his book. Part one focuses on the why-- or the foundation on which a digital minimalist philosophy is built. Part two answers the how and offers a pragmatic approach to living a digitally decluttered lifestyle.

Part one begins by presenting the case for digital minimalism with a review of the concerning aspects of social media. As many techno-apologists quickly point out, there are seemingly endless advantages to leveraging these platforms; we use these tools to stay connected with old friends or join new communities of interest. But, Newport argues, it’s not the usefulness that is at contention. It’s the loss of autonomy. He points to Michael Zeiler’s research on pecking pigeons to illustrate that unpredictability is far more enticing than a constant outcome. In humans, unpredictability triggers the release of more dopamine and, therefore, has a greater addictive nature than the predictable outcomes. The top engineers in the world are working in Silicon Valley to win our attention and they use unpredictability (the number of likes or other metrics) to entice our constant scrolling. This attention economy--think Facebook, Twitter, Netflix, news headlines etc.--has turned us, the consumers, into products, as social media giants sell your attention to the highest bidder.

To defend against this addiction, Newport proposes that consumers intentionally analyze each application and technology prior to downloading or engaging with it. He defines digital minimalism as: “A philosophy of technology used in which you focus online time on a small number of carefully selected and optimized activities that strongly support things you value and then happily miss out on everything else.”1

Instead of recommending a blanket ban on all social media, streaming services, video games, and other attention-consuming tech, Newport wisely suggests goals that are more attainable for the average digital consumer and shows his understanding of human psychology. For example, instead of deleting one’s Netflix account, Newport recommends only watching Netflix with friends or family. The principle and goal is to focus daily activities on items of true meaning and value.

Part two focuses on how to engage with and enjoy a newly decluttered lifestyle. Newport suggests prioritizing solitude, rich and complex face-to-face conversations, and genuine leisure time. He not only highlights the benefits of these activities using ancient philosophy and modern neuroscience research but he provides practical suggestions on how to implement these recommendations.

While Newport writes primarily about the digital consumer’s private decisions, I’d suggest that digital minimalism can--and should--find its way into the workplace, where emails, pings and unproductive Zoom meetings slowly eat away at productive hours and where we hone our fast-twitch muscles perusing a hundred unpredictable Slack channels, all in a futile attempt to be in the know. With the current corporate focus on health and well-being, employees should be empowered and encouraged to set digital boundaries and to focus, instead, on clear and precise deliverables.

While Newport has composed an approachable and timely work on the necessity of slowing down and being intentional, he is missing one key element. He lays out many of the negative consequences of a distracted and anxious lifestyle but fails to answer, as the catechisms of old teach, what is the chief end (or purpose) of humankind. We know what we’re against; but what are we for? Without answering this question, digital minimalism may simply be the next fad, up there with Peloton and Hello Fresh. Perhaps embracing digital minimalism will create the mental space each of us needs to answer this for ourselves.

To escape the mindless slot machine-like feedback loop of a mobile feed refresh, we may not need to “walk into the woods, to live deliberately.”2 But, Newport suggests, we must intentionally prioritize genuinely human activities like conversations and deep work in order to find the meaning this generation is craving. Perhaps Wendell Berry said it best. “Slow down. Pay attention. Do good work. Love your neighbors. Love your place. Stay in your place. Settle for less and enjoy it more.”3

Footnotes:

1. Cal Newport, Digital Minimalism:Choosing a Focused Life in a Noisy World(New York: Portfolio/Penguin, 2019),28.

2. Henry David Thoreau, Walden; or, Life in the Woods(New York: Dover Publications,2012),59.

3. Wendell Berry, The World Ending Fire: The Essential Wendell Berry(California: Counterpoint, 2017),x.

Engineer more than software

Laura Lindeman — Wed, 24 Mar 2021 16:16:27 +0000

Salesforce engineers are builders. Together, we’ve created a platform that helps companies around the world connect with their customers. Driven by our commitment to trust, equality, and innovation, we’re contributing to a more collaborative and inclusive world. Learn more at salesforce.com/tech.

Intro to automated testing in Go

Andy Haskell — Tue, 09 Mar 2021 18:47:02 +0000

This blog post is adapted from an intro to testing talk I recently did at OrlanGo's virtual meetup. You can find the slides in this GitHub repository.

There are a lot of features to the Go programming language that I really like, and one of my favorites is that writing automated tests in Go is really encouraged.

The moment you install Go, right out of the box without having to install anything else, you have access to a Go test runner for automated testing. I've personally written Go contributing to open source, working at a startup, and today working at Salesforce, and the convenience of testing in Go has always helped me build. So in this tutorial, I would like to show you:

💡 Why write automated Go tests?
🐹 How you'll use the testing package in Go
📋 What testing your Go code will look like as part of your workflow

If you're coming to Go from automated testing in Jest or RSpec or you're new to automated testing as a whole, this tutorial is for you!

💭 Why write tests?

When we're building an app, we're already maintaining a lot of code to begin with, so we should have a good reason if we're going to be writing some more. So here are some benefits to giving your code test coverage:

First, writing tests has you write out each category of scenario your code is intended to work with. This way, when you are writing the main code for your software, you have those scenarios in mind. In fact, some engineers even write out the test coverage for the code they're writing and then write the code. That technique is called test-driven development and it's not everyone's thing, but it's worth a try!

Another benefit is that since big software projects are made of smaller pieces of code, writing tests helps you make those smaller pieces of code serve as a source of truth. That way when you're building with those units of code, you have confidence that they work as expected.

Also, if you have automated testing, something machines are great at is repeating a test in exactly the same way. That's not to say manual testing doesn't have a place in software development, since you do want to make sure your app makes sense and is accessible for a human to use, but when precise repeatability is what you need, automation is your friend.

Finally, and I find Go is especially conducive to this, in a big codebase, tests serve as more documentation; if the main documentation for a Go package doesn't click for me, my next stop is to look at its test coverage to see real-world usage to a function or interface.

Sounds like some great reasons to write tests, so let's see how to write and run a test in Go!

🌺 A slothful "hello world" of Go testing

Let's start by getting some code to test in Go. If you're following along, make a folder titled sloths and put the following code into a file sloths/sloths.go. This code will tell you whether or not a string IsSlothful,

package sloths

import (
    "strings"
)

func IsSlothful(s string) bool {
    if strings.Contains(s, "sloth") {
        return true
    }
    return false
}

A string is considered slothful by this function if it contains the word "sloth".

Since we're doing a "hello world" of tests, let's test whether "hello world!" is a slothful string. Since it doesn't contain the word "sloth", we expect that IsSlothful will return false. Let's see what a Go test for that looks like. Put the following code in sloths_test.go:

package sloths

import (
    "testing"
)

func TestIsSlothful(t *testing.T) {
    if IsSlothful("hello, world!") {
        t.Error("hello, world! is not supposed to be slothful")
    }
}

Before we take a look at what's going on in the test, let's try running it. As I mentioned in the beginning, the test runner is built into Go, and what that means is under the go command, there is a test subcommand that runs the tests.

In the command line, change your working directory to your sloths directory, and run go test -v. Your command line output should look something like this:

=== RUN   TestIsSlothful
-------- PASS: TestIsSlothful (0.00s)
PASS
ok      github.com/andyhaskell/orlango-testing-talk/sloths    0.227s

Congratulations! You just ran a Go test, and it passed!

👀 Taking a closer look at our tests

Now let's see how that test worked. That was a small test function, but it has four things to bring your attention to.

First, take another look at the import block for the Go code. In addition to Go coming with its go test test runner out of the box, the Go standard library includes a testing package.

import (
    "testing"
)

The main thing in there you will be working with is its testing.T object, which we'll see provides a small set of rules for managing a Go test.

Second, there's the function signature to a Go test

func TestIsSlothful(t *testing.T) {

All Go test functions have two things in common: they take in a testing.T as their only argument, and Test is the first camelCase word of their name. This tells the go test command which functions it needs to run in a Go package.

Third, let's take a look at how we write assertions in Go. In languages like JavaScript or Ruby, a test that we expect IsSlothful to return false for "hello, world!" would look something like these, reading like a sentence in English:

expect(IsSlothful('hello, world!')).toBeFalse();

If IsSlothful returns true, then the expect fails, causing the test to fail.

In Go on the other hand, a test fails if its testing.T is made to fail. Our assertion was written in Go like this:

if IsSlothful("hello, world!") {
    t.Error("hello, world! is not supposed to be slothful")
}

If IsSlothful were to return true, then we call our T's Error method, causing the testing.T to fail with an error message explaining what went wrong. As you can see, this is a regular Go if statement; Go testing ultimately is Go code that happens to use the testing package.

In addition to t.Error, there's three other ways to make a testing.T fail:

t.Fail, which is like t.Error, but it causes the testing.T to fail without an error message
t.Fatal, which is like t.Error, but makes the test stop immediately
- This makes Fatal good for when you get an error where the results of code in the test past that point wouldn't make sense (for example if a preliminary step fails).
t.FailNow, which is like t.Fail, but it stops the test immediately.

The fourth and final thing I would like to draw your attention to is the directory structure we have so far.

.
├── sloths.go
└── sloths_test.go

All test files in Go have a name that ends with the _test.go suffix, which tells the go test command line tool where to find the test code for your Go project.

The other thing this does is for the coder. Because go test requires all your test files to be named this way, that means if you join an engineering team that does Go, or you start contributing to an open source project in Go, right on day 1 you can find where all the testing code is!

Now that we took a closer look at Go tests, let's try giving our IsSlothful function some more test coverage.

🐛 Catching a bug with a Go test

We've got our TestIsSlothful function, but it could use some more assertions. When you're writing test coverage, you want to test each general category of scenario your code works with. So for IsSlothful, that's:

Passing in a string containing the word "sloth", which should return true
Passing in a string not containing the word "sloth", which should return false as we already tested

So let's give our TestIsSlothful function some more assertions.

if !IsSlothful("hello, slothful world!") {
    t.Error("hello, slothful world! is supposed to be slothful")
}

if !IsSlothful("Sloths rule!") {
    t.Error("Sloths rule! is supposed to be slothful")
}

We're testing the strings hello, slothful world!, and Sloths rule!, expecting our IsSlothful function to return true for both of them.

Let's see if it does by running go test -v again.

=== RUN   TestIsSlothful
    sloths_test.go:17: Sloths rule! is supposed to be slothful
-------- FAIL: TestIsSlothful (0.00s)
exit status 1
FAIL    github.com/andyhaskell/orlango-testing-talk/sloths    0.207s

The test failed, but that means our test did its job; it found a bug in our IsSlothful function; the string "Sloths rule!" is not considered a slothful string, even though it contains the word "sloth".

Looking at our code, the reason why is because we were passing the string into strings.Contains to look for the word "sloth" in all-lowercase. So an uppercase "Sloths rule!" goes undetected; we should have compared the string passed in with the word "sloth", case-insensitive. And luckily, the Go strings package has a function for fixing that. Let's check that out.

  func IsSlothful(s string) bool {
+     s = strings.ToLower(s)
+
      if strings.Contains(s, "sloth") {
          return true

Before going into the if statements, we make our string all-lowercase. Now try go test -v again and your test should pass!

🏗 Trying out some Go test-driven development

With our IsSlothful function now having plenty of test coverage, we're in a good place to give it some more logic. And we need that because there's more slothful strings out there.

Sloths love eating hibiscus flowers, so a string with the hibiscus emoji is slothful. But sloths are also laid-back and not in a rush, so if a string has the hibiscus emoji but also the race car emoji, that string isn't slothful.

To try out a test-driven development workflow, let's start adding to our testing logic in sloths_test.go rather than sloths.go.

func TestHibiscusEmoji(t *testing.T) {
    if !IsSlothful("Nothing like an iced hibiscus tea! 🌺") {
        t.Error("Nothing like an iced hibiscus tea! 🌺 " +
            "is supposed to be slothful")
    }

    if IsSlothful("Get your 🌺 flowers! They're going fast! 🏎️") {
        t.Error("Get your 🌺 flowers! They're going fast! 🏎️ " +
            "is not supposed to be slothful")
    }
}

We're testing that we expect the string "Nothing like an iced hibiscus tea! 🌺" to be slothful, but that we expect "Get your 🌺 flowers! They're going fast! 🏎️" not to be slothful.

Run go test -v again and the results should look like this:

=== RUN   TestIsSlothful
-------- PASS: TestIsSlothful (0.00s)
=== RUN   TestHibiscusEmoji
    sloths_test.go:22: Nothing like an iced hibiscus tea! 🌺 is supposed to be slothful
-------- FAIL: TestHibiscusEmoji (0.00s)
exit status 1
FAIL    github.com/andyhaskell/orlango-testing-talk/sloths    0.234s

Our test failed again, but in TDD that's a good thing; in TDD we see our tests fail so that we know a test passed specifically because of our code change.

For the fix, we need to add an extra if statement to indicate that one more scenario where a string is slothful is when it contains the hibiscus emoji, but not the race car emoji.

  func IsSlothful(s string) bool {
      s = strings.ToLower(s)
+     slothsLikeThis := strings.Contains(s, "🌺") &&
+         !strings.Contains(s, "🏎️")

      if strings.Contains(s, "sloth") {
          return true
+     } else if slothsLikeThis {
+         return true
      }
      return false
  }

With our new piece of logic added, we're ready to try the test again.

Run go test -v one more time and...

=== RUN   TestIsSlothful
-------- PASS: TestIsSlothful (0.00s)
=== RUN   TestHibiscusEmoji
-------- PASS: TestHibiscusEmoji (0.00s)
PASS
ok      github.com/andyhaskell/orlango-testing-talk/sloths    0.245s

All our tests passed; our refactor is complete!

By the way, if you have a lot of tests and want to just run a few, you can use the -run flag on go test, which only runs tests matching the regular expression passed into the -run flag.

For example, to run just TestHibiscus, you can run go test -v -run Hibiscus.

🗄 A table-testing refactor

So far in our Go tests, we have two test functions running five assertions, but they all have the same structure; we pass in a string to IsSlothful and check that the returned boolean is what we expected; if we get back the wrong result, then we run t.Error causing the test to fail.

Since all our assertions have the same structure, it would be nice if we made a helper function for our assertion so we can run our tests in one big loop. That technique is popular in Go, and it's called table testing.

To start, let's write a helper function:

func assertIsSlothful(t *testing.T, s string, expected bool) {
    if IsSlothful(s) != expected {
        if expected {
            t.Errorf("%s is supposed to be slothful", s)
        } else {
            t.Errorf("%s is not supposed to be slothful", s)
        }
    }
}

The parameters to our function are:

The testing.T; if we make a helper function that handles assertions, then that function needs access to our testing.T object so we can make the test fail if our assertion fails.
The string we want to test
The expected result of IsSlothful

Inside the helper function, we compare the result of passing our string to IsSlothful with the expected value. If the results don't match, we make the fail test with t.Errorf.

Errorf and Fatalf are variations on the Error and Fatal methods; rather than taking in just a string for our error message, we pass in a template with percent-sign parameters, and then additional arguments for "filling in the blanks", similar to fmt.Printf and fmt.Sprintf.

Now, let's set up our test cases to loop over.

type isSlothfulTestCase struct {
    str      string
    expected bool
}

var isSlothfulTestCases = []isSlothfulTestCase{
    {str: "hello, world!",                               expected: false},
    {str: "hello, slothful world!",                      expected: true},
    {str: "Sloths rule!",                                expected: true},
    {str: "Nothing like an iced hibiscus tea! 🌺",       expected: true},
    {str: "Get your 🌺 flowers! They're going fast! 🏎️", expected: false},
}

We have a slice of isSlothful test cases; if one of them fails, then the string will appear in the error message.

We have a pretty simple assertion we're testing, but if you were doing a more complicated assertion, or it isn't quite clear what is being tested (like writing test coverage for an obscure edge case), then an additional field you might add to your test case struct might be a description string that your error message can include to provide more detail on your test case if it failed.

Now let's see what our new IsSlothful function looks like:

func TestIsSlothful(t *testing.T) {
    for _, c := range isSlothfulTestCases {
        assertIsSlothful(t, c.str, c.expected)
    }
}

We loop over our isSlothfulTestCases, and we run assertIsSlothful on each one, printing the strings that failed the test if any did.

If you see code that that gets repeated a lot in your team's tests and essentially makes one logical step of the test, that might be a good opportunity to use a helper function to simplify your tests. Sometimes there might be too much detail in the code you refactor out for a helper function to be worth it. But used reasonably, custom assertions can help make your tests easier to read.

🔭 Where to check out next with tests

We've looked at how we can write Go tests with the standard library and the go test tool. But testing is a huge topic; when I presented this at OrlanGo, we had about half an hour of interesting roundtable discussion afterward on people's testing techniques. So you might be wondering where to go next.

The good news is, since testing.T handles the rules of Go tests, if you have a good grasp of the fundamentals of Go, you're already in a great place to start writing test coverage in Go; tests in Go are essentially Go code that happens to use a testing.T struct.

Additionally, because of Go's small set of syntax rules compared to many other languages, if you're going into a Go codebase and the documentation doesn't give you all the answers you're looking for on how to use some code, you can also read the tests for that piece of code. Those often illustrate how the code is intended to be used. Speaking of, contributing automated tests also is an excellent way to contribute to open source!

Also, since Go is especially popular for backend web development, Go's standard library actually provides a testing package specifically for making it easier to test your HTTP handlers and clients. net/http/httptest gives you code like an implementation of the http.ResponseWriter for checking that you got back the HTTP response you expected. Additionally it even gives you code for setting up an HTTP server your tests can use, which helps a ton when you're testing clients for web APIs.

Finally, outside the standard library, a lot of assertions, like whether two values are equal to each other, or whether a given value is nil, or whether a function errored, are so common that Mat Ryer, a famous Gopher, actually wrote a Go testing package called Testify. Inside it, you'll find a lot of assertions that feel similar to Jest or RSpec matchers. It also has a suite package, which helps you run setup and teardown code before each test case or group of test cases. My slides for the talk this blog post came from give a quick look at Testify, and you can find them in this GitHub repository.

2020 Year in Review

Laura Lindeman — Wed, 06 Jan 2021 15:11:47 +0000

2020 was (dare we say it?) an unprecedented year, but before it's fully in the rearview, we at Salesforce Engineering wanted to take a beat and look back at 10 good things that happened.

10. With our thousands of employees forced to leave their offices and work remotely, we took the opportunity to develop new practices and guidelines for distributed work. We'll be better able to effectively communicate, create, and collaborate together no matter what the next year(s) hold.

9. We published a lot of blog posts! Our top three most-read posts covered security (Easily Identify Malicious Servers on the Internet with JARM), automated testing (Automating Complex End-to-end Tests), and an open source tool for Kubernetes (A Generic Sidecar Injector for Kubernetes).

8. We sponsored the first-ever virtual Grace Hopper Celebration put on by Anita Borg and extended internship offers to a slew of folks we’re looking forward to welcoming to the team next summer.

7. In a truly strange year, almost 300 employees took to the virtual stage at conferences around the world (er, in their living rooms?) to talk about the great work they’re doing.

6. It’s no secret we love open source. We headed to the StackOverflow blog to share the complexities and rewards of open sourcing corporate software projects.

5. Speaking of open source, we dropped some cool projects this year: Best, which allows you to write JavaScript benchmarks in the same way you write unit tests and integrate it into your continuous integration workflow; the AI Economist, which is an open source framework for economic policy design; and Cloudsplaining, an AWS IAM Security Assessment tool that identifies violations of least privilege and generates a risk-prioritized HTML report, among many others.

4. We launched the FOSS Fund to donate money every quarter to a project selected by our employees; a sustainable open source ecosystem is essential for our technical future.

3. The world got to meet the Salesforce Kubernetes Platform, a substrate-agnostic Kubernetes install that handles concerns for the entire runtime stack.

2. The Buildpacks project was promoted to Incubation from the Cloud Native Computing Foundation Sandbox.

1. We announced Hyperforce, a complete re-architecture of Salesforce that uses the scale & agility of the public cloud, representing a massive, multi-year, cross-company engineering effort that we’re so proud of.

So that’s a wrap on 2020. It was a difficult year, making it all the more worth looking back on what we accomplished together! We're already back at it after taking a short breather around the holidays and hope to bring you more great stuff in 2021.

Salesforce Employees Make 178 Open Source Contributions During Hacktoberfest!

Laura Lindeman — Thu, 19 Nov 2020 14:42:44 +0000

by Alyssa Arvin, Sr. Open Source Program Manager

Salesforce engineers are builders.

Together, we’ve created a platform that helps companies around the world connect with their customers and establish lasting, trusted relationships. Whether we’re working with a small business, a nonprofit, or a Fortune 500 company, it’s our job to ensure all systems are always a go. And with thousands of customers and tens of millions of daily users on our platform, our aim is to keep pushing boundaries on just how massively we can scale.

We’re also building a team of problem solvers who believe technology creates meaningful progress when the people behind it progress together. Driven by our commitment to trust, equality, and innovation, we’re contributing to a more collaborative, inclusive, and connected world. We contribute to thousands of open source projects every year, from key technologies powering our innovation to community projects that make our world a better place.

We couldn’t let October pass without participating in Hacktoberfest. This year looked a little different and it actually came with better results!

This year we had 52 people participate in Hacktoberfest with a 178 total open source contributions! Almost half of the participants made 4 or more contributions. Our employees also gave 71 hours to volunteering through open source.

How did we run Hacktoberfest at Salesforce?

The biggest theme of our Hacktoberfest was.... THEMES! We came up with themes for each week to help inspire people to contribute. The themes were:

Week 1: Project you know & love
Week 2: Projects that were released by Salesforce employees
Week 3: Projects we depend on at Salesforce
Week 4: Volunteering through open source

Our employees didn’t have to stick to the themes. If they wanted to make contributions throughout the entire month to one project they loved, then they could do that! However, the themes were really helpful in getting new open source contributors to see what projects were out there.

“It's a great introduction to the open source world and has a lot of community support that beginner contributors are looking for.” - Swati Kothari

This year we skipped things like tech talks, office hours, and synchronous events and instead encouraged people to contribute when they wanted to. The great thing about this is that it allowed anyone to participate no matter what time zone they were working in. We had a huge turnout from our employees in India and Tel Aviv.

“This was really fantastic, exciting and energetic event. I was quite amazed to see many Salesforce employees all around the globe participating in various open source projects while working from home. And I am sure anyone who loves coding to the core would feel the same.” -Viraj Jasani

We also followed DigitalOcean’s lead to make Hacktoberfest easier on open source projects. We encouraged our employees to use Hacktoberfest’s list of projects and to only make meaningful contributions. For projects that were released by Salesforce employees, we made sure the maintainers wanted their project listed as an opportunity. The projects listed under the volunteering theme were previous projects that we had used, so we knew the maintainers were comfortable accepting contributions.

Reflections

It is always fun to try new ways to get people contributing to open source. What are some ways that you have encouraged employees? Let us know on Twitter @SalesforceEng.

How an SRE became an Application Security Engineer (and you can too)

Laura Lindeman — Wed, 28 Oct 2020 13:24:24 +0000

by Breanne Boland

I realized I found security really interesting early on in my career as an engineer, back in 2015. It was a useful complement to infrastructure and networking, the other interests I quickly picked up. However, while security roles are notoriously hard to fill, they’re also notoriously hard to get when you haven’t had one before. I assumed security work would be something I’d pursue once I felt more grounded in my skills as a site reliability engineer – meaning I might have waited forever, if left to my own self-education.

Instead, early last fall, a friend reached out to me about an opening on her team at Salesforce. They wanted someone with an SRE background and security aspirations. Was I interested in pursuing it as a job, she asked, or was it just a professionally adjacent hobby?

I had to sit and think about that.

For about five seconds.

I typed back a quick ~~I VOLUNTEER AS TRIBUTE~~ extremely casual and professional confirmation that I was indeed interested in security as a career, and then the process began in earnest.

Starting the conversation, completing the interview

My interview and hiring process, from first conversation to gauge interest to phone screen to final interview, took about two months. (This was longer than is typical for this role, as I was out of town for three weeks when I first applied.) I have an eclectic resume, as you’ll learn later, and, during my interview process with Salesforce, I got to highlight things that I have learned in different ways: through casual conversations, the formal interview, and even some impromptu network diagramming on a whiteboard when I realized my hand gestures were not up to conveying the complexity of what we were discussing. (Spoiler alert for preparing for a security interview, which I’ll talk much more about later in this post: if in doubt, it’s always the OWASP Top Ten. Also worth checking out: Salesforce’s interviewing trail.) I was also able to meet a DevOps architect who, like me, thinks it’s extremely important to encourage junior engineers, which gave me a good feeling about Salesforce being a place I could be supported to successfully make the move into AppSec. We benefit enormously from diverse experience, so I was glad to know I was being assessed on my skills, not my years on the job or other sometimes-superficial markers of seniority. When I left after the interview, I wasn’t certain if I’d done well or not, but I felt like I’d done as well as I could have and demonstrated the things I actually know, which is a good interview in my book.

An ops CV for security

I began my career as a writer and editor. I attended code school in 2015, and my first engineering job was at a consultancy that focused on infrastructure and process. After three years of consulting, I moved to a role as a site reliability engineer (SRE). Throughout all this, I cultivated my interest in security by going to DEF CON, Women in Security and Privacy (WISP), Day of Shecurity, and the many other security events that take place in the Bay Area. It became clear pretty quickly that ops and security have a lot of things in common – that is, beyond a reputation for being risk-averse and more than a little curmudgeonly.

There are skills that are essential for both, including:

Networking, infrastructure, AWS, and port hygiene
Coding, especially scripting; Bash and Python are great choices but aren’t the only valid ones
Command line skills
Looking up running processes and changing their state
Reading and manipulating logs

The skills that are less explicitly required but that I’ve found to be really useful include:

Communication, both written and verbal
Documentation creation and maintenance
Teaching
A UX-centered approach

Here’s what I mean by that last one: I have some education in UX principles and practices, and I’ve done official UX exercises as part of previous jobs. I’m still able to, if needed. The part of it I use most often, though, is what I’ve come to think of as a UX approach to the everyday. (Beginner’s mind is a similar idea.) What I mean by that is the ability to come into a situation with someone and assume that you don’t understand their motivations, previous actions, or context, and then to work deliberately to build those by asking questions—while resisting the very normal human inclination to think that you totally understand this other person’s situation well before you actually understand it. The key part is remembering that, even if someone is doing something you don’t think makes sense, they most likely have reasons for it, and you can only discover those by asking them.

This was useful in ops, when I was often dealing with app engineers who weren’t familiar with my part of our systems, and it’s useful in security, when an incomplete understanding of why people do what they do can result in processes that no one will use and vulnerabilities left unchecked. It makes you nicer to deal with, yes, but also much more effective in your work.

My accidental security education

Here’s something I only realized after getting this job: I’ve done a LOT of security learning since becoming an engineer. I just didn’t fully realize what I’d been doing because I thought of it as just having fun. Meaning: I did none of these things with interview preparation in mind. The closest I came was thinking, “Oh, I see how this might be useful for the kinds of jobs I might want later, but I’m definitely not pursuing them right now.” It’s a great way to get an education in something, with no pressure and all of the enthusiasm of the hobbyist, but I realize it’s not going to be accessible for everyone.

These are the things I did over the last four years that ended up being really helpful as I went through this process:

Going to DEF CON four times
Going to Day of Shecurity three times
Being a beta student for an eight-part course all about writing secure code from a friend’s security education startup
Attempting Capture the Flags (CTFs)
Talking security with my ops coworkers, who all have opinions and stories
Volunteering for AWS IAM work whenever it came up as a task
Classes at the Bradfield School of Computer Science in computer architecture and networking (I suggest getting a company to pay for this)

Every one of these things gave me something that either helped me feel more adept while interviewing or that I was able to mention when answering questions and discussing the job. Four years is a lot of time to pursue something casually, especially since I went to an event at least every month or two.

I’ve also benefited from industry newsletters, especially these:

The Cloud Security Reading List
Julia Evans’s weekly emailed engineering comics
Devops Weekly
SRE Weekly
Crypto-Gram from Bruce Schneier

Many of these are ops-centric, but all of them have provided something to this most recent professional transition. Very few issues and problems exist in only a single discipline, and these digests have been really useful for seeing the regular intersections between things I knew and things I wanted to know more about.

Interview preparation, done deliberately

Once the interview was scheduled, I dove into interview studying. I made a wishlist of everything I wanted to be able to talk confidently about, prioritized it, and began working through everything I could. I touched on about half of it, as it was an ambitious list. I studied for about a week and a half, a couple hours at a time. I focused on three main things:

Exercism, primarily in Python
The OWASP top ten from 2013 and 2017
Blog posts that crossed my current discipline and the one I aspired to

The Exercism work was because I never feel like I code as much as I’d like in my jobs, and I feel more confident in technical settings when I feel more fluent in code. The OWASP reading was a mix of official resources, their cheat sheets, and other people’s writing about them; reading different perspectives is part of how I wrap my head around things like this. And the blog posts were for broader context and also to get more conversant about the intersection between my existing skills and the role I was aspiring to. Studying a high-profile breach that happened due to misconfigured AWS IAM permissions, something I was already well versed in, was really useful for this.

(Read about our open source project Policy Sentry automates least privilege in AWS IAM.)

Here’s a grab bag of some of the other things I read, watched, and used that helped me feel better prepared for the interview.

The great and terrible thing about infosec education is that there are so many resources out there for you to learn from. Pick a couple of things you want to get really good at (ideally that you already know something about, that’s already important to your current job or field of study) and keep digging into them. The other thing I’d recommend, which I hear suggested less often, is making sure you can explain what it is you’re trying to understand to another person. I have a couple non-engineer people in my life who let me explain things to/at them, and it’s the single best thing I do to make sure I actually understand something, instead of that inaccurate feeling of “understanding” that actually means “I read that, and the individual sentences made sense,” which is a bit different - and not something you want to realize in the middle of an onsite.

No, really: you can too

I want to leave you with some more general ideas of how to shape your career to more effectively get to the security role you might be seeking.

Find a couple security-essential skills you already know something about and dive deeply into them. For instance: I have a lot to say about IAM stuff, in AWS, Jenkins, and general principle of least privilege contexts, so that’s been something I’ve really focused on when trying to convey my skills to other people. Find what you’re doing that already applies to the role you want, and get conversational in it. Keep up on news stories relevant to those skills. This part shouldn’t be that hard, because these skills should be interesting to you. If they aren’t, choose different skills to focus on, and keep that in mind as you continue figuring out the right place for you in security.

While you’re doing this learning, make sure the people in your professional life know what you’re doing. This can be your manager, but it can also be online communities, coworkers you keep in touch with as you all move companies, and anyone else you can speak computer or security with. Don’t labor in obscurity; share links, mention things you’ve learned, and search for other people interested in the same things.

Build that community further by going to meetups and workshops. When I think about living outside the Bay Area, one of the things that would be hardest to give up is all the free education that’s available. Day of Shecurity, OWASP in SF and the south bay and so many more—and with everything being online now, there are so many more resources available from wherever you live. Follow some infosec folks on Twitter, search on meetup.com, and find your people.

Finally, remember that security needs you. Like all of tech, security is better when there are a lot of different kinds of people working out how to make things and fix things. Please hang in there and keep trying. And good luck. <3

How to Build a VS Code extension for Markdown preview using Remark processor

Laura Lindeman — Tue, 13 Oct 2020 13:31:22 +0000

Add missing remark preview support by writing your own extension.

Author:

Subrat Thakur (subrat.thakur@salesforce.com)
LinkedIn: https://www.linkedin.com/in/subrat-thakur/

Introduction

Visual Studio Code (VS Code) is a cross-platform, light-weight code editor created by Microsoft for Linux, Windows, and macOS. VS Code has support for extensions to add extra capabilities. If a feature you want is missing, you can create an extension to add it.

In my case, I wanted to be able to use a Markdown processor other than the one natively supported by VS Code. VS Code supports Markdown files out of the box and targets the CommonMark Markdown specification using the markdown-it library. But there is no way to use another markdown processor like remark, common marker, or showdown instead of markdown-it in default preview. You can definitely change the style by adding CSS to update the look and feel but the internal processor will stay as markdown-it. So, I decided to create my first VS Code extension! In addition to sharing this specific extension in the Marketplace, I wanted to outline the steps I took to build it, so that you can build an extension for a feature you want to see.

The very first step of building a VS Code Extension

To get started, install the following if you haven’t already:

VS Code
Node.js
Yeoman: An open-source client-side scaffolding tool that helps you kickstart new projects.
vscode-generator-code: A Yeoman generator to generate a new Visual Studio Code extension project from a template.

To install Yeoman and vscode-generator-code: npm install -g yo generator-code

VS Code extensions support two main languages: JavaScript and TypeScript. So having basic knowledge of either of these is pretty mandatory.

Generate a VS Code Extension Template

Go To ‘Terminal’ (‘Command Prompt’ in case of Windows), navigate to the folder where you want to generate the extension, type the following command, and hit Enter:

yo code

At the prompt, you must answer some questions about your extension:

What type of extension do you want to create? New Extension (TypeScript).
- To know about other type of extension you can go through : What can extensions do ?
What’s the name of your extension? (in my case it was Remark Preview)
What’s the identifier of your extension? (consider it Visible Name in small-case separated by -) e.g remark-preview
What’s the description of your extension? Write something about your extension (you can fill this in or edit it later too).
Initialize a Git repository? This initializes a Git repository, and you can add set-remotelater. To create an extension Git repo is not a mandatory thing. You can publish it directly from your local as well.
Which package manager to use? You can choose yarn or npm; I will use npm.

Hit the Enter key, and it will start installing the required dependencies. And finally you will get:

Your extension remark-preview has been created!

To start editing with Visual Studio Code, use the following commands:

 cd remark-preview
 code .

The project's structure

Once you are done with generating the extension template and open it in VS Code, your editor will look like this:

The generator-code project creates the most basic wiring and plumbing needed for a functioning extension. If you look in the extension directory, you’ll see several files:

vsc-extension-quickstart.md provides some instructions for creating and using the extension.
extension.js is the actual code for the extension. The entire extension doesn’t need to fit into this one file, but this is the default entry point for the extension.
jsconfig.json controls how the project’s JavaScript code is handled by the Node.js runtime. You generally don’t need to change anything here.
package.json contains the packaging information for your extension. If you are a Node.js developer, some of this might look familiar since name, description, version, and scriptsare common parts of a Node.js project.

I will talk about the files more, but, for now, let’s try running our basic extension.

// This will install all the dependencies
npm install

// This will compile your code 
npm run compile

// Run the code by hitting f5
f5

The above code instructions will open a new VS Code window with your basic extension installed in it.

What’s different inside Package.json ?

There are a few sections that are very important.
- engines: States which version of VSCodium the extension will support
- categories: Sets the extension type; you can choose from Languages, Snippets, Linters, Themes, Debuggers, Formatters, Keymaps, and Other
- contributes: A list of commands that can be used to run with your extension
- main: The entry point of your extension
- activationEvents: Specifies when the activation event happens. Specifically, this dictates when the extension will be loaded into your editor. Extensions are lazy-loaded, so they aren't activated until an activation event occurs

Let’s focus on few concepts that are crucial for VS Code extension development:

Activation Events: events upon which your extension becomes active. This will be part of package.json e.g

//the extension becomes activated when user runs the `Hello World` command
"activationEvents": [
  "onCommand:opendocs.helloWorld"
],

This is currently there inside your newly generated projects package.json

A few more example would be:
EX 1:

//This activation event is emitted and interested extensions will be activated 
// whenever a file that resolves to a certain language gets opened.

"activationEvents": [
  "onLanguage:markdown"
]

As we are planning to develop an extension for markdown, the above could be suitable for our extension ⬆️

EX 2:

// This activation event is emitted and interested extensions will be activated 
// whenever a folder is opened and the folder contains at least one file 
// that matches a glob pattern. 
"activationEvents": [
  "workspacecontains: package.json"
]

EX 3:

//The `*` activation event is emitted and interested extensions will be activated 
// whenever VS Code starts up.
"activationEvents": [
  "*"
]

You can also provide multiple multiple event as "activationEvents" is an array.

Contribution Points

Static declarations that you make in the package.json Extension Manifest to extend VS Code. This could be used to add commands available in command pallets, menu bar, editor title, editor context as well as configurations related to the extension.

Commands: Contribute the UI for a command consisting of a title and (optionally) an icon, category, and enabled state.

Configuration: Contribute configuration keys that will be exposed to the user. The user will be able to set these configuration options as User Settings or as Workspace Settings, either by using the Settings UI or by editing the JSON settings file directly.

menus: Contribute a menu item for a command to the editor or Explorer. The menu item definition contains the command that should be invoked when selected and the condition under which the item should show.

keybindings: Defining key binding for window (linux) and mac for each command.

Command Palette: When registering commands in package.json, they will automatically be shown in the Command Palette (⇧⌘P). To allow more control over command visibility, there is the command palette menu item. It allows you to define a when condition to control if a command should be visible in the Command Palette or not.
Sorting of groups: Menu items can be sorted into groups. The order inside a group depends on the title or an order-attribute. The group-local order of a menu item is specified by appending @<number> to the group identifier

Registering a command

vscode.commands.registerCommand binds a command id to a handler function in your extension. This will be part of extension.js by default (or whatever entry point you mentioned in package.json).

Once you are done adding these few points your extension will be in good shape in terms of configuration. Let’s talk about our goal to generate a preview.

Generating Preview

We already decided that we would use remark processor to process our markdown, but the most important question is: how are we going to show it inside VS Code?

So the one word answer for it is Webview.

What is Webview ?

As per VS Code documentation, the webview API allows extensions to create fully customizable views within Visual Studio Code. For example, the built-in Markdown extension uses webviews to render Markdown previews. Think of a webview as an iframe within VS Code that your extension controls. A webview can render almost any HTML content in this frame, and it communicates with extensions using message passing.

So the flow is going to be very simple :

Create HTML of our Markdown content using remark.
Add it to Webview as content.
Show that Webview in VS Code!

Simple, right?! I promise it is simpler than it sounds!

SO, let’s begin.

Create HTML content from Markdown content

This code sample will turn markdown into HTML. In our case, instead of creating another Markdown compiler instance, we will use @sfdocs-internal/compiler package .

import admonitions from 'remark-admonitions';
import * as html from 'remark-html';
import * as remark from 'remark';

function markdownCompiler(): any {
    const admonitionsOptions = {};

    return remark()
        .use(html)
        .use(admonitions, admonitionsOptions);
}

let currentHTMLContent = await markdownCompiler().process(markdownContent);

You need to add the below entries to package.json and run npm install to install new dependencies:

        "remark": "12.0.1",
        "remark-admonitions": "1.2.1",
        "remark-html": "12.0.0",

Create a Webview Panel

// Create and show a new webview
this.panel = vscode.window.createWebviewPanel(
        // Webview id
        'liveHTMLPreviewer',
        // Webview title
        '[Preview] ' + fileName,
        // This will open the second column for preview inside editor
        2,
        {
            // Enable scripts in the webview
            enableScripts: true,
            retainContextWhenHidden: true,
            // And restrict the webview to only loading content from our extension's `assets` directory.
            localResourceRoots: [vscode.Uri.file(path.join(this.context.extensionPath, 'assets'))]
        }
 );

Add HTML to Webview Content

this.panel.webview.html = await markdownCompiler().process(markdownContent);

Finally, this is what your extension.ts should look like:

import * as vscode from 'vscode';
import { admonitions } from 'remark-admonitions';
import * as html from 'remark-html';
import * as remark from 'remark';
import * as path from 'path';


export function activate(context: vscode.ExtensionContext) {

    // commandId
    const SIDE_PREVIEW_COMMAND = 'remark.sidePreview';

    const disposableSidePreview = vscode.commands.registerCommand(SIDE_PREVIEW_COMMAND, async () => {
        initMarkdownPreview(context);
    });

    context.subscriptions.push(disposableSidePreview);
}

async function initMarkdownPreview(context: vscode.ExtensionContext) {
    const panel = vscode.window.createWebviewPanel(
        // Webview id
        'liveHTMLPreviewer',
        // Webview title
        '[Preview]',
        // This will open the second column for preview inside editor
        2,
        {
            // Enable scripts in the webview
            enableScripts: true,
            retainContextWhenHidden: true,
            // And restrict the webview to only loading content from our extension's `assets` directory.
            localResourceRoots: [vscode.Uri.file(path.join(context.extensionPath, 'assets'))]
        }
    );
    panel.webview.html = await markdownCompiler().process(vscode.window.activeTextEditor?.document.getText());
}

function markdownCompiler(): any {
    const admonitionsOptions = {};
    return remark()
        .use(html)
        .use(admonitions, admonitionsOptions);
}



// this method is called when your extension is deactivated
export function deactivate() { }

You can make it more modular and efficient.

Now let’s talk about few more things that might be useful for your new preview extension.

Developer Tools for Webview

As I already told you, Webview is very similar to a Web Browser; you can actually inspect the Webview Panel, check the console logs, and debug any script added to it when the Webview is open. To do all this, open Command Palette (⇧⌘P) and Search for “Developer: Open Webview Developer Tools.” This will open a developer console very similar to Chrome browser.

Content security policy for Webview

Content security policies further restrict the content that can be loaded and executed in webviews.

To add a content security policy, put a <meta http-equiv="Content-Security-Policy"> directive at the top of the webview's <head>.

Here's a content security policy that allows loading local scripts and stylesheets (inline as well), and loading images over https:

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; img-src ${panel.webview.cspSource} 'self' 'unsafe-inline'; script-src 'nonce-${nonce}'; style-src ${panel.webview.cspSource} 'self' 'unsafe-inline'; font-src ${panel.webview.cspSource}">

The ${webview.cspSource} value is a placeholder for a value that comes from the webview object itself.

We can also load the scripts and css in old fashion way if we use vscode uri path instead of relative path.

function **getDynamicContentPath**(context, panel, filepath) {
    const onDiskPath = vscode.Uri.file(path.join(context.extensionPath, filepath))
    const styleSrc = panel.webview.asWebviewUri(onDiskPath);
    return styleSrc
}

VS Code creates a secure URI for webview panel and makes it accessible for Iframe.

<link rel="stylesheet" type="text/css" href="${getDynamicContentPath(context, panel, 'assets/css/admonitions.css')}">

How to interact with Webview through Messages?

As we all know by now, Webview is content inside an iframe, so we need special messaging to send events to Webview.
So whenever we want to send a message we can use something similar to:

private postMessage(msg: any) {
        // here this flag is to check if webview panel is still alive or not
        if (!this._disposed) {

        // this.panel is the instance of Webview Panel
            this.panel.webview.postMessage({
                        type: 'messageFromExtension',
                        line: visibleRanges});
        }
    }

Now let’s see how to catch this message inside Webview. The most important thing is that this script should be part of the HTML that we add to Webview panel.

window.addEventListener('message', event => {
    const message = event.data;
    if (message.type === 'messageFromExtension') {
        console.log('Line : ' + message.line[0][0].line);
        onUpdateView(per);
    }
});

In a very similar fashion, we can catch any window event of Webview as well like scroll, click, double click, etc.

For example:

window.addEventListener('scroll', throttle(() => {
    console.log("Scroll Event in Webview window");
}, 100));

To send any message back to VS Code, we need to use acquireVsCodeApi.

// acquireVsCodeApi is the api to talk to extension from webview
const vscode = acquireVsCodeApi();

// createPosterForVsCode is a class provided by VSCode
const messaging = createPosterForVsCode(vscode);
messaging.postMessage('revealLine', { line });

And in the same way, we need a subscribe method for any events coming from Webview:

//this should be part of extension and no need to load inside webview
this.panel.webview.onDidReceiveMessage(e => {
     console.log(e.body.line);
});

Publishing Extensions

To publish an extension, you need to set up a few things.

Install VSCE : vsce, short for "Visual Studio Code Extensions," is a command-line tool for packaging, publishing and managing VS Code extensions. You can use vsce to easily package and publish your extensions. It can also search, retrieve metadata, and unpublish extensions.

To install VSCE: npm install -g vsce

Get a Personal Access Token: You need to create an account on Azure Dev. You can log in using Github as well. Once you log in, you have to create a project; you can probably name it VSCode Extensions. Once you are done, let’s move ahead to create Personal Access Token.
- Open the User settings dropdown menu next to your profile image (top right corner) and select Personal access tokens:
- On the Personal Access Tokens page, click New Token to create a new Personal Access Token
- Give the Personal Access Token a name; optionally, you can extend its expiration date to one year, make it accessible to every organization, or select a custom defined scope ruleset:
- Finally, scroll down the list of possible scopes until you find Marketplace and select Manage:
- Select Create and you'll be presented with your newly created Personal Access Token. Copy it; you'll need it to create a publisher.
Create a publisher : A publisher is an identity that can publish extensions to the Visual Studio Code Marketplace. Every extension needs to include a publisher name in its package.json file.

Use this command to create publisher : vsce create-publisher

Use this command to login : vsce login

Publish your extension: As the final step, publish your extension to marketplace.

Use this command to publish : vsce publish

Keep in mind you always need to change version in package.json before re-publishing the extension, or else it will throw an error. You can use a command like vsce publish minor or vsce publish 2.0.1 .

Wrapping up

One message I want you to take to heart is that creating a VSCode extension is not as hard as it looks. It is pretty simple, actually. Sometimes you just need to push yourself a bit and try things out.

VS Code is awesome 😎 and it’s really amazing how we can extend functionality inside it by developing extensions.
There are many helpful APIs that will help you create the extensions you want to build. The VS Code extension API has many other powerful methods you can use.

If you want to take a look at the whole project the code is available here, which might help for code references (watch out for some messy code though!) and you can also find it in the marketplace.

Reference

VS Code Extension Sample
VS Code Extension DOC
Workbench Extension

Salesforce Standup with Jae Taylor

Laura Lindeman — Mon, 28 Sep 2020 18:43:47 +0000

Welcome to the Salesforce Standup, where we check in with employees in our Technology, Marketing, and Product organization from locations all over the world! At every Standup we ask our guest some questions to help us get to know them better. As any good standup should be, it's a quick chat where we’ll find out answers the questions that matter most—or maybe are just the most fun. You’ll have to watch to find out.

Today's guest, Jae Taylor, is a director of Product Management for Service Delivery at Salesforce. That means he drives the efforts to make sure our platform, which so many people depend on, is highly available and highly performant.

Outside of work, Jae is passionate about the importance of mentorship, which he's seen at play throughout his varied career. He's not a morning person but has started running first thing and finds it makes him more alert and productive throughout the day. And, he loves spending time with his kids building video games.

Catch the whole interview to find out more about Jae!

We caught up with @JaeInTech in the latest edition of the #SalesforceStandup. He loves Korean food, building games with his kids in @unity3d, and starting his day on his @onepeloton treadmill! Watch the video to learn what new gadget has changed the way he uses his phone pic.twitter.com/AGhR65IsYG
— @SalesforceEng (@SalesforceEng) September 25, 2020