This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/4] add case for probe timer


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]