Auto generated Test Code
This is a small concept paper which helps to understand some rules for the code “to be generated” in order to make the Nunit tests something easier to write and to read. Actually in openpetra a set of yaml-files describe the content and the layout of the used dialogs. This yaml-files are used to create a set of c#-files (auto generated code).
A yaml file which is responsible for a dialog named Example.yaml generates the files Example.cs, Example.Designer.cs and Example.ManualCode.cs and each of the file holds a part of the complete class TFrmExample.
The content of Example.Designer.cs is very unique and contains the basic definition of the controls, its initialization and integration into the form. Example.cs is generated by one of a set of different templates and contains a data binding code to the server and its database. The Example.ManualCode.cs file is the only file which shall be used for manual and problem specific code.
The program openpetra itself shall be tested by NUnit-forms and according to the idea in defined in Comments to Revision 1089 the follwing rules are outlined.
To understand the situation we have to notice that an Assert must not necessarily placed inside of the [Test]-code itself and can also be done in the routines below. In order to demonstrate this, I’ve placed an Asssert.AreEqual(true,false) inside of a constructor and an Assere.AreEqual(true,true) inside a test itself. Both tests are running well and in case of an failed test you will get shown the correct error comment.
So we have to do the following.
- We have to parallelize the inheritance path of the controls and the testers. If we have developed an own tree view from the System.Windows.Forms.TreeView control for example TtrvTreeView, then the TtrvTreeViewTester-Class shall inherit TreeViewTester of NUnit.
- For each self developed control we have do develop a set of tests and for each test we have to decide if a test is necessary only one time – in this case this shall be placed inside of each use – in this case the test can be placed inside its own tester.
So we have following types of tests:
- A test of a control
- A test inside of a control tester
- A test of an arrangement of a set of controls i.e a form or a group of forms which represents an special openpetra function.
Basic rule shall be: Keep the price for the tests as low as possible. This means the price for the development of the code on one hand and for the periodically running of the tests on the other one. Code coverage tests of a control shall be placed inside a specific control test itself. Tests inside of the control testers shall only be used for the tests of proper use of a control.
For example if there exists a tab control and the tester will click onto a button on a tab which is not been shown, then this is a improper use of a control and this shall result in a failed test. An other example may be a click onto a button which is disabled or invisible. In both cases the click event shall be overridden and inside of the click the message shall be shown.