1 person found this helpful
I set it up like this:
A page template contain the QUnit framework (js, css, minimum markup)
QUnit tests created as seperate clientlibs, categorized with a shared string (all in the category qunit.tests)
Then I skipped ahead of my plans and ideas and just included the entire clientlib I was aiming to test alongside the qunit clientlib on that page template. That's a quick way of setting it up.
In the long term my idea is to utilize the clientlib dependency functionallity to "tag" QUnit-tests with dependencies towards a specific components.
I place the test script in another clientlibrary, named QUnit.Granite.Component
the QUnit.Granite.Component then depend on Granite.Component, and have the category QUnit.base.
My page template that contain the QUnit framework would then only include the clientlib QUnit.base, and this clientlibrary would embed/depend exactly what would be needed to run tests toward the components that have them.
As for automation, my project already use Silenium for other reasons, so I took another quick path of automating the tests by writing a simple silenium test that would navigate to a page containing this page template and thereby running the actual QUnit tests, the silenium test then watch the qunit-header to see if it passed or failed. But I suppose the last step don't matter one bit, a headless driver ran by grunt, for example, should work just like my Silenium test without any modifications to the actual structure.
My advice, let CQ handle the relations of qunit-code vs tobetested-code for you. Clientlibs seems to do the job just fine :-)