Testing container-bound script safely

[Bill Korbholz]

Hi folks,

I have a script bound to a Google spreadsheet. It is accessible to several colleagues. I'm trying to figure out how to test my code in a "sandbox" such that my colleagues will still use the "official" code. Deploying the code doesn't seem to address the issue. And I don't want to make copies of the spreadsheet because it contains data that would have to be synchronized.

Most of my code exists in a library, and my first attempt was to deploy the library. Works great, but since the container refers to the version of the library, all users will be executing the same code. So I still don't have a sandbox.

[Ed Robinson]

Hi Bill,

Yes the sandbox exists, but you have to know where to look for it.

in the Google cloud console, look for the OAuth consent screen, you'll see "3 Test users" (see attached image)

You can add your test-buddy's email addresses here. They will get access to your SS.

Ed

[Michael O'Shaughnessy]

I do like Ed's idea however I can say from experience that libraries have versions.  YOU as the owner (and any other EDITORS) of the script will always have access to the "HEAD" version which has the most current code.  So let's say you have deployed your library and it is at version 5.  All the users will use version 5.  You then change some of the code and add extra functionality.  You and your editors can test it because you will be using the HEAD version of the library while everyone else is using version 5.  Now let's say you are ready to "deploy" your new updated code.  You would then deploy a new version (let's say 6 now) and then you would need to instruct all your users to update the library version.  This is very simple and you can send them a screen case of how to do it.  

This method has worked for me on several projects that I have worked on (and are still working on!!!😁)

Hope this at least gives you something to think about.

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/aeb0d6bd-77ef-48de-8203-98405895a496n%40googlegroups.com.

[Ed Robinson]

Hmmm... Thanks Michael, your comments made me re-read the original question again. 

Bill: Is the following what you're trying to do?

Set things up, so effectively there are two scripts attached to a sheet:

1. A development script, plus library you can develop privately, and

2. A live script, plus library version for your people to use 

Both development + live access same data in the live spreadsheet. 

Your development script remains private to you, until you deploy it to your users
--

[Bill Korbholz]

Ed (and Michael),

Thanks for your responses. One key bit of information that I forgot to mention is that my spreadsheet resides in a shared drive. So all of my colleagues access the same file (see p.s.). It's become clear to me now with your comments that the best way for me to test changes is:

1. Use deployments in my library and make sure that my spreadsheet's apps script refers to the proper deployment. That's just good development practice.
2. To test changes, I'm just gonna make a copy of my spreadsheet and then include all of my library code in the test copy's apps script so that I can use the debugger (sure wish you could use the debugger with library code!). When I'm happy with my changes, I'll upload them to the library, deploy a new version, and edit the production copy of the spreadsheet to point to the new version.

The fact that the production and test versions of my spreadsheet may contain different data is really not important, upon further thought.

Bill

p.s. An interesting consequence of sharing the file is that when one user executes a function that changes data in the spreadsheet, all users see the changes. That's proven to be both good and bad. But since I have a very small user community, and we're all friends!, it works out.

[Ed Robinson]

This sounds like a good approach. 

- A separate copy of the sheet you use for Dev

- Both Prod and Dev sheets bound to different versions of the library

It would be good to have some mechanism to ensure the production version of the sheet is bound to the right library version.

[Michael O'Shaughnessy]

I do hear you about being able to debug libraries!!  I can offer some help with this...

First, I have used a modified version of Andrew Roberst "BBlog" library.  Here is the repo: https://github.com/andrewroberts/BBLog?tab=readme-ov-file

Once you get the hang of it, you can use "try/catch" error trapping and have it log info to a spreadsheet.  You can at least "see" what happened.

Second, and I wish I had time to investigate this one, is a solution from Bruce McPherson.  He has an approach of "inlining" libraries so you test and debug then with one simple switch of a variable the code goes back to using the library.  Here is the link to more information: https://ramblings.mcpher.com/apps-script/add-ons/inline-libraries/

If you DO use his approach PLEASE share how it worked for you!!

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/8a47f5cd-ae0a-41e4-8ef6-c4c9c503f1ccn%40googlegroups.com.

[Bill Korbholz]

I looked at McPherson's approach for inlining libraries. I had developed my own approach years ago out of necessity. It may not be as elegant as McPherson's (although I can't evaluate that since I don't really understand it), but it works. My script that refers to the library simply has a bunch of lines like this:

   function onOpen(e) {Library.onOpen(e);}

   function someFunction {Library.someFunction;}

   ...

where someFunction is replicated for each of the functions that are menu item functions (I've got 16 of 'em in this 1 application).

Then when I want to test the library, I comment all of those lines, effectively bypassing the library, and copy/paste the library code below.

As I said, it ain't elegant but it works and I understand it, which is what matters.

Bill

[Keith Andersen]

I'm not versed in libraries - I wish I could find a good thorough teaching on it. That said, why not create a "New" version and do all the testing in that version using the test URL? If it works, deploy it, if it doesn't, no harm no foul. Everyone is still on the previous version and none the wiser the testing was even done.

And again, does anyone know a good teaching on libraries?

Keith 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/b5a072fb-187e-4a33-a6f2-96757ea7406fn%40googlegroups.com.

[Bill Korbholz]

The reason I used a library in the first place was to place my code in a separate file outside of my Google docs. Why? Because my organization depends heavily on shared drives, and we are concerned that a file may be inadvertently (or maliciously) deleted by someone and we don't notice it until more than 30 days have passed, hence no way to recover it. So we are using a 3rd-party solution to back up all of our shared drives daily (incremental backups). The trouble with that is that all Google docs are backed up as their Microsoft equivalents, e.g. Excel, Word, Powerpoint. Not only are those imperfect renditions, but they don't contain any of the attached Apps script. So be externalizing all of my script into libraries (standalone script files), I've got good solid backups (all script files are backed up as text files).

Bill