@item
Clearly state in your @file{TESTCASE} file what each test is supposed
to test. You should be testing not only the common case, but testing
@item
Clearly state in your @file{TESTCASE} file what each test is supposed
to test. You should be testing not only the common case, but testing
-corner cases. Specify what criteria or issue is being tested. For
-example, in testing @func{thread_join} you would have specified that
-you test @func{thread_join} when it is called multiple times on the
-same child thread.
+corner cases. Specify what criteria or issue is being tested.
-Make your tests as succinct as possible. Most students in the past
-have done a great job with the testing of @func{thread_join},
-creating very succinct short tests. We like that.
+Make your tests as succinct as possible.
@end example
@noindent The compiler is quite likely to notice that the value that you
write to the array is never used again and thereby decide not to write
@end example
@noindent The compiler is quite likely to notice that the value that you
write to the array is never used again and thereby decide not to write
improvements that your code makes to the performance of the system.
You should be able to show us ``before'' and ``after'' performance
data, and explain how the data shows the improvement. For example,
improvements that your code makes to the performance of the system.
You should be able to show us ``before'' and ``after'' performance
data, and explain how the data shows the improvement. For example,
from a workload for the non-Solaris scheduler and the Solaris
scheduler and explain why the Solaris scheduler is better.
from a workload for the non-Solaris scheduler and the Solaris
scheduler and explain why the Solaris scheduler is better.