Comprehensive overview of QUnit testing for controls.
If you stick to these rules, you will find it much easier to refactor/maintain your tests. Keeping the tests atomic will make debugging much easier, because you will hit your breakpoints for the code being tested only. If you write QUnits without keeping to these rules, you may well not notice anything bad to begin with, but you will eventually end up in the middle of a maintenance nightmare!
Internally, we use three templates for testing. The one shown below is the general control template. If you are using Eclipse, a description of how you can import the templates is included at the end of this section.
Use the following pattern to structure your tests. If everyone sticks to this same pattern, you will be able to read your colleagues' tests very quickly:
QUnit.test("Should do Something", function (assert) { // Arrange // System under Test var oMyControl = new nameSpace.myControl({ }); // Act // Assert // Cleanup oMyControl.destroy(); });
Arrange
In Arrange, you should set up the dependencies and options you need for your System under Test.
System under test
In System under Test, you should create your control and you should also render it if you want to test the rendering.
Act
Ideally, this part is only one single line of code executing the function you want to test.
Assert
This part may contain multiple statements of QUnit assertions, but ideally not too many in total.
Make sure that you also test negative paths, not only the expected ones.
Optional: Cleanup
Here you should destroy all the controls/models you created.
If you don't use Sinon sandboxes, revert all the spies/stubs/mocks.
In the rendering tests part, you have to place your control in the DOM. The best place to put it is the qunit-fixture div, since its content gets deleted after every test.
Make sure you destroy your control, since SAPUI5 will keep a reference to it and may also rerender it.
It's crucial that you call sap.ui.getCore().applyChanges() after each time you have caused a rerendering.
The call to this function synchronizes the changes of your control with the DOM. If you do not make this call, the DOM will not be updated.
You can use the following template to make sure that you don't forget to destroy your control:
QUnit.test("Should do Something", function(assert) { // Arrange var oContructor = { }; // System under Test var oMyControl = new nameSpace.myControl(oContructor); oMyControl.placeAt("qunit-fixture"); sap.ui.getCore().applyChanges(); // Act // Assert // Cleanup oMyControl.destroy(); });
Sinon fake timers
If you are using sinon.qunit, it will automatically use fake timers by itself. Fake timers will prevent any setTimeout/setIntervall function from being executed, unless you call this.clock.tick(milliseconds) in your test. This means that a Mock Server with auto-respond will not respond and OPA will not be able to wait for controls.
In addition, control events might be fired inside of a setTimeout(, 0), so the event might not be triggered at all.
Testing SAPUI5 control events with Sinon
If you want to test SAPUI5 events, you can use spies to test how often they are called. If you try to test the parameters, however, you cannot do this with spies as SAPUI5 uses an eventPool that reuses the same object again. This means that after an event is set, all of the parameters will be deleted, Sinon will keep a reference to the object without properties.
The effect of this is that you cannot assert on them anymore. The workaround is to use a stub with a custom implementation that saves a copy of the parameters to your test function scope.
An example of this is shown in the cookbook below (events).
I've set a property on my control: Why aren't the changes in the DOM?
The most likely reason for this is that sap.ui.getCore().applyChanges() was not called. SAPUI5 does not render synchronously, but calling this function will render immediately.
If you are using Eclipse, to import the templates start by calling up Preferences as shown below:
Make sure that you have added the JavaScript Editor to the File Associations under :
You can do this by choosing the File Associations link on the Editors start page, then selecting *.html from the top list and adding JavaScript Editor as an associated editor:
While still in the Preferences, navigate to and choose Import...:
After doing this, you test press Ctrl + Space in your js/html files and start writing your test.
The following templates are available: