Remember that output of any action code is normally to set/alter one or more attributes. Here are a few things I've learned from testing action & export code…
You can view attribute values in many ways other than note window key attributes (and more effectively so):
In addition, if an initial attempt at a piece of code doesn't work then consider:
- Breaking down nested and chained expressions so each step results in an attribute. You can then inspect interim values/data formats and check they are as expected.
- Verifying queries in agents before adding any action code.
- Using an agent to test queries used inline in find(), collect() and the like. Does such an agent query return the items you expected in your action code?
- The context of action when using offset attribute reference - i.e. an attribute other than the note in context.
- Allowing for the possibility that some codes may note evaluate inputs - i.e. they only accepts literal values.
- The context of execution when using agent actions - are you setting the original's attributes or just those of the alias in the agent? This matters in relation to intrinsic attributes.
- Making a test rig with a smaller dataset to filter out the noise of testing on an already large/complex TBX (this also pre-empts accidental data damage from badly written user actions). Bear in mind that notes, prototypes, attributes, etc., can be drag-copied from a main to a test TBX so set-up is not as onerous as it may appear.
- Using 'code' notes with built-in Code prototype. The 'Code note' concept is storing action code in text of (another) note. This makes it easy to see/edit code and use intending, etc., whilst any edits still have immediate effect.
Also consider Export code contexts for debugging.
