[PATCH 1/4] add case for probe timer

[PATCH 1/4] add case for probe timer

[Zhou Wenjian]

	* testsuite/semko/timer_hz_randomize.stp: New test case
---
 testsuite/semko/timer_hz_randomize.stp | 6 ++++++
 1 file changed, 6 insertions(+)
 create mode 100755 testsuite/semko/timer_hz_randomize.stp

diff --git a/testsuite/semko/timer_hz_randomize.stp b/testsuite/semko/timer_hz_randomize.stp
new file mode 100755
index 0000000..c4d4c6a
--- /dev/null
+++ b/testsuite/semko/timer_hz_randomize.stp
@@ -0,0 +1,6 @@
+#! stap -p2
+
+probe timer.hz(1000).randomize(500) {
+	printf("%s\n", "timer_hz")
+	exit()
+}
-- 
1.8.3.1

[PATCH 2/4] add cases for condition compile

[Zhou Wenjian]

	* testsuite/systemtap.base/cond_compile.exp: New test case
	* testsuite/systemtap.base/cond_compile.stp: New test file
---
 testsuite/systemtap.base/cond_compile.exp |  9 +++++++++
 testsuite/systemtap.base/cond_compile.stp | 33 +++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+)
 create mode 100755 testsuite/systemtap.base/cond_compile.exp
 create mode 100755 testsuite/systemtap.base/cond_compile.stp

diff --git a/testsuite/systemtap.base/cond_compile.exp b/testsuite/systemtap.base/cond_compile.exp
new file mode 100755
index 0000000..654708a
--- /dev/null
+++ b/testsuite/systemtap.base/cond_compile.exp
@@ -0,0 +1,9 @@
+# Check condition compile
+
+set test "cond_compile"
+if {![installtest_p]} { untested "$test"; return }
+
+set result_string {arg==2015
+arg==2015
+arg!=2014}
+stap_run3 "$test" $srcdir/$subdir/$test.stp 2015
diff --git a/testsuite/systemtap.base/cond_compile.stp b/testsuite/systemtap.base/cond_compile.stp
new file mode 100755
index 0000000..481deb3
--- /dev/null
+++ b/testsuite/systemtap.base/cond_compile.stp
@@ -0,0 +1,33 @@
+/*
+ * cond_compile.stp
+ *
+ * Check condition compile
+ */
+
+probe begin {
+    %(
+     $1==2015%?
+     {printf("arg==2015\n")}
+    %)
+
+    %(
+     $1==2014%?
+     {printf("arg==2014\n")}
+    %)
+
+    %(
+     $1==2015%?
+     {printf("arg==2015\n")}
+    %:
+     {printf("arg!=2015\n")}
+    %)
+
+    %(
+     $1==2014%?
+     {printf("arg==2014\n")}
+    %:
+     {printf("arg!=2014\n")}
+    %)
+
+    exit()
+}
-- 
1.8.3.1

[PATCH 4/4] add cases for var type

[Zhou Wenjian]

	* testsuite/semko/num2string.stp: new test case
	* testsuite/semko/string2num.stp: new test case
---
 testsuite/semko/num2string.stp | 9 +++++++++
 testsuite/semko/string2num.stp | 9 +++++++++
 2 files changed, 18 insertions(+)
 create mode 100755 testsuite/semko/num2string.stp
 create mode 100755 testsuite/semko/string2num.stp

diff --git a/testsuite/semko/num2string.stp b/testsuite/semko/num2string.stp
new file mode 100755
index 0000000..28aa8b6
--- /dev/null
+++ b/testsuite/semko/num2string.stp
@@ -0,0 +1,9 @@
+#! stap -p2
+
+probe begin
+{
+        var_num=2008
+        var_num="HelloWorld"
+	printf("string:%s\n", var_num)
+	exit()
+}
diff --git a/testsuite/semko/string2num.stp b/testsuite/semko/string2num.stp
new file mode 100755
index 0000000..c896a40
--- /dev/null
+++ b/testsuite/semko/string2num.stp
@@ -0,0 +1,9 @@
+#! stap -p2
+
+probe begin
+{
+        var_string="HelloWorld"
+        var_string=2008
+	printf("num:%d\n", var_string)
+	exit()
+}
-- 
1.8.3.1

[PATCH 3/4] add cases for var definition

[Zhou Wenjian]

	* testsuite/parseko/var_definition1.stp: New test case
	* testsuite/parseko/var_definition2.stp: New test case
---
 testsuite/parseko/var_definition1.stp | 7 +++++++
 testsuite/parseko/var_definition2.stp | 7 +++++++
 2 files changed, 14 insertions(+)
 create mode 100755 testsuite/parseko/var_definition1.stp
 create mode 100755 testsuite/parseko/var_definition2.stp

diff --git a/testsuite/parseko/var_definition1.stp b/testsuite/parseko/var_definition1.stp
new file mode 100755
index 0000000..d92bf03
--- /dev/null
+++ b/testsuite/parseko/var_definition1.stp
@@ -0,0 +1,7 @@
+#! stap -p1
+
+probe begin
+{
+	0var=2015
+	exit()
+}
diff --git a/testsuite/parseko/var_definition2.stp b/testsuite/parseko/var_definition2.stp
new file mode 100755
index 0000000..f48cb6f
--- /dev/null
+++ b/testsuite/parseko/var_definition2.stp
@@ -0,0 +1,7 @@
+#! stap -p1
+
+probe begin
+{
+	var=2015a
+	exit()
+}
-- 
1.8.3.1

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

[Frank Ch. Eigler]

Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com> writes:

> 	* testsuite/semko/timer_hz_randomize.stp: New test case
> [...]

Thanks for this and the other test cases in this batch.  I wonder how
you chose these particular areas, and what extra coverage they
provide.  (Tests that are highly redundant with the rest of the
testsuite are not that valuable.)

- FChE

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

["Zhou, Wenjian/周文剑"]

On 11/13/2015 10:26 PM, Frank Ch. Eigler wrote:
>
> Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com> writes:
>
>> 	* testsuite/semko/timer_hz_randomize.stp: New test case
>> [...]
>
> Thanks for this and the other test cases in this batch.  I wonder how
> you chose these particular areas, and what extra coverage they
> provide.  (Tests that are highly redundant with the rest of the
> testsuite are not that valuable.)
>
> - FChE
>

I have a testsuite for systemtap. And some of cases in it hasn't been covered
by the internal testsuite. So I think this will do some help to the internal
testsuite. So ... that's how I chose these cases.
Of course, I will filter the meaningless cases out. But I still can't make sure
that the cases I sent are indeed valuable. So I need some help during this work.

-- 
Thanks
Zhou

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

["Zhou, Wenjian/周文剑"]

On 11/13/2015 10:26 PM, Frank Ch. Eigler wrote:
>
> Zhou Wenjian <zhouwj-fnst@cn.fujitsu.com> writes:
>
>> 	* testsuite/semko/timer_hz_randomize.stp: New test case
>> [...]
>
> Thanks for this and the other test cases in this batch.  I wonder how
> you chose these particular areas, and what extra coverage they
> provide.  (Tests that are highly redundant with the rest of the
> testsuite are not that valuable.)
>
> - FChE
>

I have reviewed the cases in this batch but can't figure out why
they are redundant. Could you tell me more about that? I will be
very appreciated and I can also take it into consideration when
dealing with the following cases.

-- 
Thanks
Zhou

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

["Zhou, Wenjian/周文剑"]

Hello Frank and David,

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.
Both will help me a lot.

-- 
Thanks
Zhou

On 11/13/2015 05:25 PM, Zhou Wenjian wrote:
> 	* testsuite/semko/timer_hz_randomize.stp: New test case
> ---
>   testsuite/semko/timer_hz_randomize.stp | 6 ++++++
>   1 file changed, 6 insertions(+)
>   create mode 100755 testsuite/semko/timer_hz_randomize.stp
>
> diff --git a/testsuite/semko/timer_hz_randomize.stp b/testsuite/semko/timer_hz_randomize.stp
> new file mode 100755
> index 0000000..c4d4c6a
> --- /dev/null
> +++ b/testsuite/semko/timer_hz_randomize.stp
> @@ -0,0 +1,6 @@
> +#! stap -p2
> +
> +probe timer.hz(1000).randomize(500) {
> +	printf("%s\n", "timer_hz")
> +	exit()
> +}
>

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

[David Smith]

On 11/26/2015 02:53 AM, "Zhou, Wenjian/周文剑" wrote:
> Hello Frank and David,
> 
> 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.
> Both will help me a lot.

I can't really speak for Frank, but I took a further look at the
testcases. Here's what I found:

PATCH 1/4 (timer testcase): Checked in

PATCH 2/4 (conditional compile): This testcase looks like it tests the
same things as testsuite/systemtap.base/preprocessor.exp. If you feel
like your testcase found something that one doesn't, we can add new
subtests to preprocessor.exp.

PATCH 3/4 (add cases for var definition): Checked in.

PATCH 4/4 (add cases for var type): This one looks very similar to
testsuite/semko/typedefinition.stp. Once again if you feel like your
testcase found something this one doesn't, we can add new subtests to
typedefinition.exp.

Thanks again for the tests.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

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

["Zhou, Wenjian/周文剑"]

On 12/01/2015 05:48 AM, David Smith wrote:
> On 11/26/2015 02:53 AM, "Zhou, Wenjian/周文剑" wrote:
>> Hello Frank and David,
>>
>> 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.
>> Both will help me a lot.
>
> I can't really speak for Frank, but I took a further look at the
> testcases. Here's what I found:
>
> PATCH 1/4 (timer testcase): Checked in
>
> PATCH 2/4 (conditional compile): This testcase looks like it tests the
> same things as testsuite/systemtap.base/preprocessor.exp. If you feel
> like your testcase found something that one doesn't, we can add new
> subtests to preprocessor.exp.
>

Thanks a lot for pointing it out.

> PATCH 3/4 (add cases for var definition): Checked in.
>
> PATCH 4/4 (add cases for var type): This one looks very similar to
> testsuite/semko/typedefinition.stp. Once again if you feel like your
> testcase found something this one doesn't, we can add new subtests to
> typedefinition.exp.
>

I reviewed the typedefinition.stp and I found that it can't work as expected.
So I rewrite it. I will describe it exactly following the rewriting patch.

> Thanks again for the tests.
>


-- 
Thanks
Zhou

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

[Frank Ch. Eigler]

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.

- FChE

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

["Zhou, Wenjian/周文剑"]

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