If you're licensed to use the API outside of Unity scripts-
If your scripts get complex, or if you just are spending a lot of time testing/debugging simple things, the next step after Eric's suggestion and Shane's suggestion may be to start writing scripts in a way that can be executed outside of the Unity Script.
Write all your business logic in a method(s) that accepts the inputs you need, and can be run *without modification* from Visual Studio or a lighter weight tool like VSCode or LINQPad.
Only pass inputs that you can recreate outside of the Unity Script. Don't pass the args object- you can't easily create one for testing. Pass things like the app object and the args.Document object. If you query an external database using a Unity Connection String, pass the database connection into your method(s) so that you can create a comparable connection outside of the Unity Script.
You can also structure your overall business logic with this in mind. Instead of having a Unity Script set Keywords, you might have the script calculate a value and set a property, which Workflow can use to set a Keyword. Don't do this if it is just extra complexity, but it may let you build business logic ("calculate what this value should be for this document") that can be written *and executed* in an IDE quickly, instead of writing in Studio, build/publish/reset manual actions in a client to trigger Workflow / look at results.
In some cases this might even lead to automated testing outside of the Unity Script, but it can be very without ever expecting to automate testing.
Re-structuring code to execute outside of your Unity Script will add some complexity to the simplest things, and in some cases can be misleading (some things behave differently inside a Unity Script), but even very small debugging problems can often be much more pleasant with an IDE and debugger than with a build/publish/reset/execute/view diagnostics/guess/change/add more diagnostics/build/publish... cycle.
