Testing Plan 1.1.Interrupt

[DanielBullimore]

Link to Feature List: #26

Testing Method:

Manual / User Testing:

1 check o.class.js exists in library directory

Programmatic Testing:

Interrupt will be subjected to programmatic testing via a HTML document which will load o.class.js in its header. The document will run a script which will compare the class's state with that of the written description ( #26 ), progress and results are printed to the document. The testing script will then declare an instance of o() in a non repeating interrupt state and assign a simple function to that instance's funAct() interface. That function will increment numCycleCount by one and print the instances state to the document. A setTimeout will then be defined to execute the interrupt instance's funAct() method after numCycles. The testing script also declares another instance, sets its state as a repeating task and assigns a function via the funSolve() interface. That function will print the state of the new instance and decrease numExecutions by one unless its value is zero. The test will then implement a setInterval to execute the instances funSolve() method. When numExecutions reaches zero the interval must be unset and the first instances funAct() method will be called.

[Attach / Upload testing program and link it]

Pass Criteria

Security, Accessibility & Visibility:

Pretest state:

o() is a public class all its properties and methods are public

Post testing state:

-

Other/Notes:

-

Interface & display:

Pretest state:

Interrupt objects never render on the GUI thus users will never interact with them visually.

Post testing state:

This test will out put some results as text on the document.

Other/Notes:

[notes]

Persistent Memory:

(what does the system know about this feature?)

Pretest state:

o() class exists in javascript namespace. two instances of o() have been declared. instance one state:

• numCycles = 2000
• booActOrSolve = true
• booRepeat = false
• numCycleCount = 0
• numExecutions = 0 funAct() is type function funSolve() is undefined

instance two state:

• numCycles = 1000
• booActOrSolve = false
• booRepeat = true
• numCycleCount = 0
• numExecutions = 5 funAct is undefined funSolve is type function

Post testing state:

[Define this feature's required persistent memory post-testing states]

instance one state:

• numCycles = 2000
• booActOrSolve = true
• booRepeat = false
• numCycleCount = 2
• numExecutions = 0 funAct() is type function funSolve() is undefined

instance two state:

• numCycles = 1000
• booActOrSolve = false
• booRepeat = true
• numCycleCount = 0
• numExecutions = 0 funAct is undefined funSolve is type function

Other/Notes:

In this test one cycle is 1ms. This wont be the case when interrupts are implemented by game loop. Comparison of the instance states will be used to confirm the functions are executing and the cycle count and executions values are changing.

Restrictions:

Interrupt's funAct() and funSolve()interface must accept new functions to be assigned at declaration time. Those new functions must be executable from within setTimeout and setInterval. Otherwise Game Loop's design will fail.

Exceptions:

As a public class with all visible properties and methods Interrupt objects have no internal data type validation. They are best executed within error handling environments. Example if a boolean property is set to string or array logic checks on that interrupt will cause un-handled errors.

[DanielBullimore]

Hi Test Panners. I'm in testing phase one for this feature. Its clear the type of unimplemented interface can never return type null. Officialy requesting to change the expected result from null to undefined. I can deliver this feature now should my request be granted.

[DanielBullimore]

Officialy requesting to change the expected result from null to undefined

request granted