This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH 1/3] add testcases for function definitions
- From: "Zhou, Wenjian/åæå" <zhouwj-fnst at cn dot fujitsu dot com>
- To: Josh Stone <jistone at redhat dot com>
- Cc: <systemtap at sourceware dot org>, David Smith <dsmith at redhat dot com>
- Date: Tue, 10 Nov 2015 10:50:22 +0800
- Subject: Re: [PATCH 1/3] add testcases for function definitions
- Authentication-results: sourceware.org; auth=none
- References: <1447059456-19811-1-git-send-email-zhouwj-fnst at cn dot fujitsu dot com> <5640E0EE dot 2060803 at redhat dot com> <56415207 dot 6050905 at cn dot fujitsu dot com> <56415718 dot 2010100 at redhat dot com>
On 11/10/2015 10:31 AM, Josh Stone wrote:
On 11/09/2015 06:10 PM, "Zhou, Wenjian/åæå" wrote:
I think either of them is enough to generate the correct result.
Why should stap_run still make sure nothing comes after matching
the exact output?
Because people make mistakes. Perhaps the test.exp looks for 5 success
lines, but the test.stp outputs 6 lines - this should be flagged. The
extra line might have been added later, forgetting to update test.exp
too. And if the extra line of output happens to report a failure, we
don't want to miss that.
Checking that nothing comes after is a way to be sure that we really are
matching exact output.
I don't think it is necessary to concern about case authors' mistakes
in the test suite.
And between them, I prefer matching the exact output.
You mean between "+" and "{5}"? Explicit counts are fine with me, but I
don't like manually repeating the match string.
Yes, I just mean the "+" and "{5}".
To make sure nothing comes, we have to modify all cases which use the
stap_run. I don't think it's a good idea that modifying the cases which
are working well.
If my probe-final-"EOF" idea works, then we can implement that entirely
in stap_run, without modifying any testcases.
Eh, if it works, I think the "{5}" won't be needed.
But I doubt whether it will introduce errors to some cases.
I will think more about it.
--
Thanks
Zhou