Unit Testing: Difference between revisions
Jump to navigation
Jump to search
[unchecked revision] | [unchecked revision] |
Content added Content deleted
(Partial undo revision 11214 by Love4boobies (Talk) - fixed context) |
m (→The idea is that...: As per L4B) |
||
Line 3: | Line 3: | ||
== The idea is that... == |
== The idea is that... == |
||
* if you later change things in the implementation code, the test driver tells you if the results remain the same (regression test); |
* if you later change things in the implementation code, the test driver tells you if the results remain the same (regression test); |
||
* if you receive a bug report, you do not only fix the implementation code, but also update the test driver so that this bug could never be |
* if you receive a bug report, you do not only fix the implementation code, but also update the test driver so that this bug could never be introduced again without failing unit testing. |
||
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. |
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. |