Anonymous user
Unit Testing: Difference between revisions
no edit summary
[unchecked revision] | [unchecked revision] |
m (→The idea is that...: As per L4B) |
No edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 1:
'''Unit testing''' means that, in addition to the implementation code, you also write a "test driver" that puts the implementation code through a set of trials, checking the returns for correctness. Note that this is done during development / testing - the "test driver" is not shipped with the released code.
== The
*
*
Unit testing is a great way to improve the reliability and correctness of your code. However, it requires that the code to-be-tested actually ''can'' be run under control of the test driver. It should be easy to see where this becomes tricky. While it ''should'' be possible to test most kernel functions in a "testbed" test driver, the really "juicy" stuff like interrupt handling, process dispatching or memory management are probably not unit-testable.
Line 9:
== Alternative / Additional Option: Run-Time Self-Tests ==
*
* If your memory manager has some 'free zone merging' feature, allocate as much 'small' zones as you can, then free all the 'odd' zones and then all the 'even' zones (stressing the merge feature). When you're done, try to allocate a single zone as large as the collection of all the small zones you initially get.
*
*
As many of those tests may hang, you're suggested to print what test you're running before you know if the test was successful or not.
[[Category:
|