Testing and updating in a collaborative environment can be hard. Here's how it works to minimize merge problems
- Communicate what you're working on before starting
- Work on service separately where possible - for Example if A is working on Drive, B should work on Sheets
All tests are now modular and should contain sections that tests what you're working on - for example.
testutilities.js
// all these imports
import is from '@sindresorhus/is';
import '@mcpher/gas-fakes'
// all the fake services are here
//import '@mcpher/gas-fakes/main.js'
import { initTests, wrapupTest } from './testinit.js'
// this can run standalone, or as part of combined tests if result of inittests is passed over
export const testUtilities = (pack) => {
const {unit, fixes} = pack || initTests()
unit.section("utilities base64 encoding", t => {
// ... tests
})
unit.section("utilities zipping", t => {
//.. tests
})
// etc..
if (!pack) {
unit.report()
}
return { unit, fixes }
}
// if we're running this test standalone, on Node - we need to actually kick it off
// the provess.argv should contain "execute"
// on apps script we don't want it to run automatically
// when running as part of a consolidated test, we dont want to run it, as the caller will do that
wrapupTest(testUtilities);The package.json should contain a reference to the test
"scripts": {
"test": "node ./test/test.js",
"testdrive": node ./test/testdrive.js execute",
....etc
},
they can be run individually with - for example
npm run testdrive
The consolidated test.js should contain references to all known tests
import '@mcpher/gas-fakes'
import { initTests } from './testinit.js'
import { testDrive } from './testdrive.js';
import { testSheets } from './testsheets.js';
...etc
const testFakes = () => {
const pack = initTests()
const {unit} = pack
// add one of these for each service being tested
testSheets(pack)
testDrive(pack)
...etc
unit.report()
}
// this required on Node but not on Apps Script
if (ScriptApp.isFake) testFakes()
and can be run with
npm run test
When testing and you want to use the local files rather than @mcpher/gas-fakes, you can have a local package.json in the same folder as your tests which directs the package to a local file. just run npm i to install
"dependencies": {
"@mcpher/gas-fakes": "file:../../"
}
where the file value points to the root of gas-fakes. If you want to instead use the npm version then just revert that normal npm syntax and install again.
execute bash togas.sh to copy all files to apps script IDE. All tests can be run there either indivually or as a whole just like on Node
- gas fakes intro video
- getting started - how to handle authentication for restricted scopes.
- readme
- gas fakes cli
- ksuite as a back end
- msgraph as a back end
- apps script - a lingua franca for workspace platforms
- Apps Script: A ‘Lingua Franca’ for the Multi-Cloud Era
- running gas-fakes on google cloud run
- running gas-fakes on google kubernetes engine
- running gas-fakes on Amazon AWS lambda
- running gas-fakes on Azure ACA
- Yes – you can run native apps script code on Azure ACA as well!
- Yes – you can run native apps script code on AWS Lambda!
- initial idea and thoughts
- Inside the volatile world of a Google Document
- Apps Script Services on Node – using apps script libraries
- Apps Script environment on Node – more services
- Turning async into synch on Node using workers
- All about Apps Script Enums and how to fake them
- colaborators - additional information for collaborators
- oddities - a collection of oddities uncovered during this project
- named colors
- sandbox
- senstive scopes
- using apps script libraries with gas-fakes
- how libhandler works
- article:using apps script libraries with gas-fakes
- named range identity
- adc and restricted scopes
- push test pull
- sharing cache and properties between gas-fakes and live apps script
- gas-fakes-cli now has built in mcp server and gemini extension
- gas-fakes CLI: Run apps script code directly from your terminal
- How to allow access to sensitive scopes with Application Default Credentials
- Supercharge Your Google Apps Script Caching with GasFlexCache
- Fake-Sandbox for Google Apps Script: Granular controls.
- A Fake-Sandbox for Google Apps Script: Securely Executing Code Generated by Gemini CLI
- Power of Google Apps Script: Building MCP Server Tools for Gemini CLI and Google Antigravity in Google Workspace Automation
- A New Era for Google Apps Script: Unlocking the Future of Google Workspace Automation with Natural Language
- Next-Generation Google Apps Script Development: Leveraging Antigravity and Gemini 3.0
- Modern Google Apps Script Workflow Building on the Cloud
- Bridging the Gap: Seamless Integration for Local Google Apps Script Development
- Next-Level Google Apps Script Development
- Secure and Streamlined Google Apps Script Development with gas-fakes CLI and Gemini CLI Extension
- Secure and Conversational Google Workspace Automation: Integrating Gemini CLI with a gas-fakes MCP Server
- A Fake-Sandbox for Google Apps Script: A Feasibility Study on Securely Executing Code Generated by Gemini CL

