[PATCH 1/4] add case for probe timer
"Zhou, Wenjian/周文剑"
zhouwj-fnst@cn.fujitsu.com
Tue Dec 1 02:57:00 GMT 2015
On 12/01/2015 06:37 AM, Frank Ch. Eigler wrote:
> Hi -
>
>> I try to send essential cases, but I can't make sure all of the cases
>> are needed.
>> So I need your help. If you have time, you can tell me why the cases have
>> no sense, or you can just let me know which are meaningless.
>
> The general idea is to check for duplication. If you are testing a
> language control flow construct, see if there is already ample usage
> of that same construct already in the testsuite. If you are testing a
> probe point, see if that same point, or a close member of the family,
> is already well-represented. The other idea is that for new tests for
> fairly old/static parts of code are probably not worth much effort,
> that code having been proven over time.
>
> For example, the cond_compile test is thoroughly covered already by
> other stuff; check all the %( %) preprocessor usage in the tapsets as
> well as other testsuite script. The semko ones don't look too
> duplicative, but also don't relate to recently-changed code. I
> wouldn't oppose those going into the testsuite, but the slight extra
> cost of making the test runs longer counts slightly against them.
>
Thanks a lot for your detailed description.
I got that and I will try my best to avoid the duplicate cases.
But at one point, I have some different ideas.
I don't think the cases should only focus on the recently-changed code.
The cases should make sure that the code can work as expected.
If we only focus on the recently-changed code, I don't think the testsuite
can do much more help than just reviewing the changed code by eyes .
--
Thanks
Zhou
More information about the Systemtap
mailing list