Unit Testing: Difference between revisions
Jump to navigation
Jump to search
| [unchecked revision] | [unchecked revision] |
Content added Content deleted
(changed category: osdev->troubleshooting) |
|||
| 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 not only fix the implementation code, but also |
* if you receive a bug report, you not only fix the implementation code, but also wirte a test driver so that this bug is not reintroduced. |
||
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. |
||