Document a use case of shared 'intialization code' for testing

[jakub-g]

A frequent use case coming from teams who started as DDT (Development-Driven-Tests, do a lot of development and then start writing tests) is that they have a significant codebase with e.g. their templates depending on global variables, on certain settings in Aria environment, customized default widget libs (defaultWidgetLibs / $wlibs) etc. -- all of those things are usually set in some kind of index.htm and are executed before the root template is loaded.

When they try to write test for their templates, they have lots of errors due to lack of those settings, and they're lost.

We have some means to fight this problem, but they should be better documented.

For instance, if running Attester, there's extraScripts entry in the attester YAML/JSON config, which can be used for
a) injecting 3rd party libraries (equivalent of <script src="foo.js"> in index.htm)
b) providing some kind of env.js file with app settings (equivalent of usually inline declarations calling aria.core.Environment.setEnvironment etc)

However some people are running the Old Test Runner, which is better for them for debugging - I mean this one:

It can be run via attester on a URL like
http://localhost:7777/campaign1/__attester__/aria-templates/interactive.html
(if attester is run with --predictable-urls true) - there's a link "debug this campaign" once you start attester

However the Old Runner can be also started outside of Attester, and then probably there's no option of injecting extrascripts...

One solution to this problem would be to create a custom class my.app.MyTestCase extending aria.jsunit.TestCase which would do some initialization in $constructor - however if the team is using TestCase, TemplateTestCase, ModuleControllerTestCase etc. they'll have to do it for each class like that...