You are here: Home V2 Software Software More ... Developer Notes Legacy Notes Code Testing

Code Testing

Proposals and discussion for code testing.

ntroduction

Evetually we will need some kind of testing, even if it is partial. It is hard to find the best way, though. Testing each function separately might require up to a million lines of code - if we write it by hand we lose the advantage of autogeneration, and if we generate it we would not have an independent test. A comprehensive model, to test all different cases, should be enough to test the generation machinery, at least. Unfortunately a comprehensive model might be too large see below) so we might have to make do with a subset.

Here are some considerations to get started.

Object types

For each simple data type we would need a series of valid and invalid values, and the errors that the latter should raise.  The simple data types are so simple (sorry) that this should be a manageable job. We just need a testing framework to store them in.

For memopsObjects and DataObjTypes the constructors would have to be checked separately. For the simple purpose of checking the effect of what types you pass in, a small set of acceptable and unacceptable types would suffice. We would need some thinking to set up the test model so that all relevant inheritance (etc.) situations were catered for. We would need special tests for TopObjects and objects in the Implementaiton package

 

Attributes and roles

There are many aspects that make a differece:

  • Cardinality, we have 0..1, 1..1, 0..n 0..infinity, n..m, and n..infinity.
  • for hicard != 1 we also have isUnique yes/no and isOrdered yes/no
  • Changeability, could be none, frozen or (eventually) add-only
  • For attributes this could get us 48 different possibilities, which is about possible.
  • Links can be either one-way or two-way and may have any of the 48 possibilities on the defined ends. That would make for up to 2400 different kinds of link for a comprehensive test model, thogh many combinations aer not possible. This  is already more than you would want to add in by hand - we would need to choose a subset or generate the model semiautomatically.
    We would further need to consider intrapackage versus out-of-package links, parent links, and child links.
  • Atributes and links can be derived. Each derived attribute has a handcoded function, but just checking the generic parts of the code would double the number of cases.

 

Object states

Objects can exist in the states  'inConstructor - yes/no' 'isReading - yes/no', and 'override yes/no'. Not all combinations are allowed, but for comprehensive testing we might need to try half a dozens states .
Since isReading and Override are global switches, and you cannot create more than one object at a time, we do not need to try sets of objects in different combinations of states.

 

Handcode

Anything that involves handcode will need special, handcoded tests. Simple data types are already discussed. This leaves attribute, role and class constraints, all explicitly entered functions, as well as constructor and destructor code. This set of tests is model specific. The problem is that the code may be quite complex, requiring many tests to guarantee, and that a large number of objects may be involved, making it difficult to set up the test situation.

 

Other

We would need special tests for the parts of object keys.