suggestion #1

[rwu2359]

In a project I am currently working on, there is a need for some validation data to be included in the header, so that the first part of documentation or the actual script can be quickly scanned.

so we are using a ValidateDate, and also because the types of validation required is dependant on a risk analysis matrix, we are also adding Complexity - which if course FMPerception gives us very nicely..

the in-house rule then is that if the validation date is completed the date is removed, and the script change can not be put into production until they have been tested and validated...

[toddgeist]

how would we implement that?

[rwu2359]

/# @validationDate
/# @validationComplexity
/# @validationTests

am keen to push further on test-driven development than I have done till now. It should be possible to create a file whose sole purpose was to test many scripts by sending both good and bad data parameters - an extension of what you have done with the CustomFunctions file... just musing out loud.

[rwu2359]

other thing that would be good in here is
/# @dependantCustom
/# @dependantExternal

for both CustomFunctions and any external (plugin dependencies) ??
again consistency when search with FMPerception could highlight all the scripts you need to test if you have change a CF - just becasue the function works in the tests file doesnt mean you ahve dealt with the Law of Unintended Consequences

[toddgeist]

jsdoc already has @requires. Isn't that good enough?

[rwu2359]

Yes, for some reason I didnt see that when reading the docs...... :(