Testing is one of the most important things you can do your code. However, when using a library that requires access to a remote system unit testing can become problematic. You don’t want to have to have a real connection and pull down real data since this is slow and requires anyone contributing to your project to set up the remote system as well. This is where mocking comes in with Jest.

Mocking allows you to detach a module from making a remote call and allows you to define the data that it returns. This means that you can modify the data how you need to provide a small data set or a large data set or even error out on demand.

In this post, we’re going to look at how to set up mocking for JSforce to test logging in and mocking out making queries.

If you’ve done much API generation then you’ll that you don’t want to have to make your users authenticate multiple times just because your API is going somewhere external. For example, if you have an API that reaches into Salesforce but your app uses Google SSO, you don’t want to have to present an oauth screen to your user after they’ve already authenticated. To work around this, you can use a JWT Bearer flow to login on behalf of a user and get a access token to work with.

There’s a new feature in Salesforce called Change Data Capture that allows you to subscribe to a Cometd endpoint and stream changes to most or some of your objects. I’ve talked in a previous post about how to get data out of Salesforce and this seems like it might be the front-runner for one of the best ways. I would still plan on ways to get data if it exceeds the three day replay period and you’ll also need a way to do your initial data import.

What data can I get with Change Data Capture?

In a perfect world, everything you’d need would always live in Salesforce and you’d never have to worry about backing up data. Well, we don’t live in a perfect world. Lot’s of times you need to get data out of Salesforce and get it into an external system. You could do this for data backup, for populating a search index, for sending messages to an external system. With Change Data Capture, you can do this type of data flow in real-time.

Change Data Capture supports the following standard object (at time of writing):

• Account
• AccountContactRole
• Asset
• Campaign
• Case
• Contact
• Event
• EventRelation
• Lead
• ListEmail
• Opportunity
• OpportunityContactRole
• Order
• OrderItem
• Product2
• Task
• User

In addition to the standard items above, Change Data Capture supports all custom objects.

Recently I started setting up some Outbound Messaging to I needed to set up a blackhole (messaging sink) for messages to go to until we had stood up the real messaging endpoint. To host this I setup a simple nodejs service on our company’s externally available (but internally hosted) instance of Openshift. This service simply sends back the appropriate ACK for any XML that is POSTed to it.

When we started working on the Apex Lodash project we knew we wanted to publicly post our code coverage percentage. To do this we chose to use coveralls.io since it is free for open source projects.

Travis CI

In a previous post I talked about how to setup Travis CI to deploy your Salesforce code automatically. We will be updating the Travis CI configuration to push the testing results to coveralls.

Coveralls

There don’t seem to be too many options around for code coverage display on the Internet. Coveralls has lots of options for various coding languages and a pretty nice interface. Like Travis CI, Coveralls is free for open source projects and they do have paid options that supports private repositories. It does support several other CI platforms if you’re not using Travis CI.

This post will probably only be useful to one other person out there, but it was a fun exercise and thought I’d at least share my output.

One of the biggest challenges I have when running tests is that I will often forget they are running and leave them completed for a while before I go back and remember I ran them. This mainly happens when I’m running an entire class worth of tests and have 5-10 minutes to kill. When first learned about JSforce and it’s cli capability I was in love! So I set out to make it so that the current testing status is displayed inside of my screen session. At the end of it all this is what I came up with: