I made a Gmail add-on that uses oauth for external API calls and shows info using cards. It works fine but I’m stuck on how to test it properly. I want to write unit and integration tests that can run on CI services like Travis.
The problem is that the add-on uses classes like CardService, OAuth2, and GmailApp which are only available in the Apps Script environment. Mocking all these functions seems like a lot of work.
Does anyone have experience with testing Gmail add-ons? How can I set up tests that will run on CI services? Any tips or best practices would be really helpful.
Here’s a basic example of what I’m working with:
function doGet() {
var card = CardService.newCardBuilder();
var section = CardService.newCardSection();
section.addWidget(CardService.newTextParagraph().setText('Hello, World!'));
card.addSection(section);
return card.build();
}
I’m not sure how to test this kind of code outside the Apps Script environment. Any ideas?
Testing Gmail add-ons can indeed be challenging. One effective approach I’ve used is to separate the core logic from the UI components. This way, you can unit test the majority of your code without relying on Apps Script-specific classes.
For the UI-related code, consider creating a thin wrapper around CardService. This allows you to mock the wrapper in your tests, rather than mocking the entire CardService API. You can then write integration tests that run directly in the Apps Script environment to verify the UI functionality.
As for CI, I’ve had success using Google Cloud Build in conjunction with clasp. You can set up a pipeline that deploys your code to a test project, runs your unit tests in Node.js, and then triggers your integration tests in the Apps Script environment.
It’s not a perfect solution, but it provides a good balance between test coverage and practicality for Gmail add-on development.
I’ve been down this road with Gmail add-on testing, and it’s definitely tricky. One approach that worked well for me was using a combination of mocking and integration testing.
For unit tests, I created mock objects for CardService, OAuth2, and GmailApp. It’s a bit of work upfront, but it pays off in the long run. You can create simple versions that just return predefined objects or values.
For integration tests, I set up a separate Apps Script project specifically for testing. I’d deploy my add-on code there and run tests within that environment. This way, you have access to all the necessary classes.
To run on CI, I used clasp to push code changes to the test project and then triggered the tests remotely. It’s not perfect, but it allowed me to catch most issues before they hit production.
Remember to focus on testing the core logic of your add-on rather than trying to test every UI interaction. It’s a balance between coverage and practicality when it comes to add-on testing.
yo, i know the pain. try using sinon.js or jest manual mocks to mimic those Apps Script functions. it’s not entirely elegant but it works in node. good luck!