Home

Welcome to the Xbox Kernel Test Suite wiki!

Any help is welcome!

I'm copying/pasting what Patrick told me about tests here, so this can be used as guideline:

Tests should be written such, that all the possible paths through the code under test get exercised So, not only normal behaviour, but also extremes must be tested, to see if the code under test behaves as it should under those circumstances too So if a function returns error codes, the test should be made such, that all those codes are hit at least once Also, any measurable effect of a function should be measured in the test, to see if the function indeed behaves as it should Additionally, tests could check that a function doesn't have any other side effect. For example : if a function clears a buffer, then bytes before and after the buffer shouldn't be altered One troublesome situation is when a function has undefined behaviour on some inputs - you already saw that on the Av tests : often, exceptions happen, or worse. Those are difficult to cover in a test. Some functions might even undermine the stability of the system (like a reboot function - that's hard to test) For those cases, I suggest to document in the testing code what problems might arise on bad input (meaning : any possible bad call) and not test it. It's safe to assume this bad behaviour would kill real software too, so not many titles would depend on bad behaviour Thus, it's all right to skip such tests, just as long as it's clear in the code that you've thought about it and decided to skip such cases (any the reason why).