Provide some high-level guidance on folders/files structure good from testing point of view

[jakub-g]

A recurring issue is also that there's also not so much documentation about how to structure the files and folders (including with testability in mind), and lack thereof creates confusion of "too much choice" for the devs. (I've had a number of questions like should this or that be in tplscript, or module controller, or in some other external file?)

(This should be a subject of discussion BTW - feel invited to comment)

For instance, IMO, the good practice is to have template scripts rather lightweight, and focus in their code on interactions with the templates (reacting to events, calling $json.setValue), and relaying the calls to the small external utility libraries whenever possible (or module controllers).

Those utility classes could be stateless $singletons exposing just static methods.

This will result with more files created, but also a cleaner design.

The singleton utility classes could be tested in separation, using a plain old javascript tests (instances of TestCase). Tests that are relying on certain behaviours of templates could be instances of TemplateTestCase.

Without that, developers might lean (because it's easier) towards creating big template scripts that are mixing in one file interactions with templates and doing "real work".

The issue with template scripts is that they are neither singletons nor can be instantiated directly (because it doesn't make sense, as tplscript should live only in connection to a template). See [1]

Hence, sth like
new my.app.MyTemplateScript
will throw and
my.app.MyTemplateScript.myFunction()
won't work.

An alternative in order to just test the tpl script "static" functions, without the need to use TemplateTestCase, would be using TestCase with $dependency on "my.app.MyTemplateScript" and calling:
my.app.MyTemplateScript.prototype.myFunction()

However if we advertise it, it should be clearly stated that by doing it this way you lose all the magic of templates, because you just have a dumb reference to a tplscript and nothing more.

In any case, the possibilities should be documented, so that AT newbies who already have lots of things to learn didn't have to go through all those issues on their own.

[1] https://github.com/ariatemplates/ariatemplates/blob/master/src/aria/Aria.js#L779

[olaf-k]

This part:

For instance, IMO, the good practice is to have template scripts rather lightweight, and focus in their code on interactions with the templates (reacting to events, calling $json.setValue), and relaying the calls to the small external utility libraries whenever possible (or module controllers).

is actually what new users are taught during the training: template scripts should only deal with display aspects while business code belongs to the controller.

With this in mind, it makes sense to test them in TemplateTestCase. I'm fine though to advertise your "dummy script" solution where it makes sense but I don't see a lot of use cases for that (provided the code is well written :)

I'm adding this issue to the task around tests documentation.