Talk:KmtestsHowto

Hi Thomas! Awesome article, but I feel I get a bit lost in some parts.

1) "add the test to kmtests\kmtest\testlist.c in alphabetic (ASCII) order" That "add" maybe needs some comments, as adding in that file the "KMT_TESTFUNC Test_newtestname" and also to { "newtestname", Test_newtestname }.

2) "add the test to kmtests\kmtest_drv\testlist.c in alphabetic (ASCII) order" Same happens here.

About RTL-tests, i got somehow confused, and there is an RtlUnicodeString in our trunk that makes me even more confused since it doesnt follow any of the two different approaches.

Since i want to add a RtlUpcaseUnicodeString test, i head directly to the section named "RTL-type tests".The instruction says:

• add the source file to kmtests\CMakeLists.txt to be included in COMMON_SOURCE.
• add the test to kmtests\kmtest\testlist.c with the normal test name (alphabetic (ASCII) order)
• add the test to kmtests\kmtest_drv\testlist.c (alphabetic (ASCII) order) with KM appended to the test name string to indicate the kernel-mode version in the source file (testname.c), define KMT_EMULATE_KERNEL, then include <kmt_test.h>, and wrap your test in the START_TEST macro as usual.

But, our current RtlUnicodeString.c,cousin of RtlUpcaseUnicodeString, doesnt follow these steps:

• YES: add the source file to kmtests\CMakeLists.txt to be included in COMMON_SOURCE.
• YES: add the test to kmtests\kmtest\testlist.c with the normal test name (alphabetic (ASCII) order)
• NO: add the test to kmtests\kmtest_drv\testlist.c (alphabetic (ASCII) order) with KM appended to the test name string to indicate the kernel-mode version
• YES:in the source file (testname.c), define KMT_EMULATE_KERNEL, then include <kmt_test.h>, and wrap your test in the START_TEST macro as usual.

RtlUnicodeString.c doesnt just define KMT_EMULATE_KERNEL but then it adds a "#ifdef KMT_USER_MODE" inside the code of the test. Is this #ifdef needed?In all cases?Just in this case?why? :)