Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <7AA2BA62-548E-4514-937B-65F769766344@gmail.com>
References: <791F7DA5-49F2-4B4A-9321-BDA01CB52E46@gmail.com>
 <CABytAGp2PuiyjdiJmLRYRzQNpd4k=FrO92jCcCsOCs8EpwQVGg@mail.gmail.com>
 <7AA2BA62-548E-4514-937B-65F769766344@gmail.com>
From: Taewoo Kim <wangsaeu@gmail.com>
Date: Wed, 27 Jan 2016 22:50:46 -0800
Message-ID: 
 <CABytAGop-JDV5QBv95GSBp5e+S8KOOD5a2dyOb6-hccNzmMFLQ@mail.gmail.com>
Subject: Re: Test Framework Improvements
To: dev@asterixdb.incubator.apache.org
Content-Type: multipart/alternative; boundary=089e013c65dcbfac6d052a5f57ed

--089e013c65dcbfac6d052a5f57ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Murtadha,

I see. Thank you for your patch. I will try to apply that.

Best,
Taewoo

On Wed, Jan 27, 2016 at 8:08 PM, Murtadha Hubail <hubailmor@gmail.com>
wrote:

> Hi Taewoo,
>
> No, this wasn=E2=80=99t caused by the improvements. However, before the
> improvements, in case of ParseException we were not returning a summary a=
t
> all in the JSON output and we were getting JSONException all the time. I
> have just submitted a patch[1] to add the stack trace in the JSON output
> and now you should be able to see the original exception stack trace in t=
he
> "Failure Trace" of Unit.
>
> You may checkout it and test it.
>
> Cheers,
> Murtadha
>
> [1] https://asterix-gerrit.ics.uci.edu/#/c/599/ <
> https://asterix-gerrit.ics.uci.edu/#/c/599/>
>
> > On Jan 27, 2016, at 10:14 AM, Taewoo Kim <wangsaeu@gmail.com> wrote:
> >
> > This is indeed a good improvement. Regarding this, I have a question.
> After
> > merging the current master into my branch, I executed "executionTest" i=
n
> > Eclipse. And I found that "Failure Trace"  stack trace in JUnit shows n=
ot
> > the origin of failure, rather it always shows "executeTest" like the
> > following for each test cases. Originally, I could be able to see the
> > origin - in this case - AQL Parser. But, now, with this summary, it is
> hard
> > to identify the origin. I have to execute each of failed test one by on=
e
> > and need to check console to see the real origin, not
> > "TestExecutor.executeTest". I am wondering this is the result of test
> frame
> > work change?
> >
> >
> > ExecutionTest
> > org.apache.asterix.test.runtime.ExecutionTest
> > [ExecutionTest 0: feeds: feeds_01]
> > test[ExecutionTest 0: feeds:
> > feeds_01](org.apache.asterix.test.runtime.ExecutionTest)
> > java.lang.Exception: Test
> > "src/test/resources/runtimets/queries/feeds/feeds_01/feeds_01.1.ddl.aql=
"
> > FAILED!
> > at
> >
> org.apache.asterix.test.aql.TestExecutor.executeTest(TestExecutor.java:59=
4)
> > at
> org.apache.asterix.test.runtime.ExecutionTest.test(ExecutionTest.java:96)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:62)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:497)
> > at
> >
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMeth=
od.java:47)
> > at
> >
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallabl=
e.java:12)
> > at
> >
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod=
.java:44)
> > at
> >
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.=
java:17)
> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> > at
> >
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.=
java:70)
> > at
> >
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.=
java:50)
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> > at org.junit.runners.Suite.runChild(Suite.java:127)
> > at org.junit.runners.Suite.runChild(Suite.java:26)
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> > at
> >
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java=
:26)
> > at
> >
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:2=
7)
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> > at
> >
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4Test=
Reference.java:50)
> > at
> >
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.jav=
a:38)
> > at
> >
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes=
tRunner.java:459)
> > at
> >
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTes=
tRunner.java:675)
> > at
> >
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunn=
er.java:382)
> > at
> >
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRun=
ner.java:192)
> > Caused by: java.lang.Exception: HTTP operation failed: 2
> > STATUS LINE: HTTP/1.1 500 Server Error
> > SUMMARY: SyntaxError: Encountered " "text" "text "" at line 32, column =
3.
> > Was expecting one of:
> >    &ltSTRING_LITERAL&gt ...
> >    &ltIDENTIFIER&gt ...
> >
> > =3D=3D>   text : string,
> > STACKTRACE:
> > at
> >
> org.apache.asterix.test.aql.TestExecutor.executeHttpMethod(TestExecutor.j=
ava:228)
> > at
> >
> org.apache.asterix.test.aql.TestExecutor.executeDDL(TestExecutor.java:329=
)
> > at
> >
> org.apache.asterix.test.aql.TestExecutor.executeTest(TestExecutor.java:43=
0)
> > ... 34 more
> >
> >
> > Best,
> > Taewoo
> >
> > On Tue, Jan 12, 2016 at 12:46 PM, Murtadha Hubail <hubailmor@gmail.com>
> > wrote:
> >
> >> Hi All,
> >>
> >> Last night Abdullah and I merged the Asterix test framework improvemen=
t
> >> change. So, don=E2=80=99t be surprised if you have a test case that wo=
rked
> >> yesterday but not on the current master.
> >>
> >> During the development of the change, we discovered and fixed critical
> >> issues such as:
> >> 1. Failed Jobs' threads that are never terminated and their operators
> keep
> >> waiting forever.
> >> 2. Many operators that do not comply with the IFrameWriter contract.
> >> 3. Indeterministic result delivery on synchronous queries.
> >> 4. Invalid number of active operations on an index after a transaction
> >> aborts.
> >>
> >> All of these issues and many others were not detected before because o=
f
> >> the state the test framework was in. I encountered test cases that wer=
e
> >> miraculously passing just because they were expected to throw an
> exception.
> >> Just to give you an example, a test case was using the DDL API to run =
a
> >> query, and an exception was thrown saying "SyntaxError: Invalid
> statement:
> >> Non-Update statement=E2=80=9D and it was considered as passing, even t=
hough the
> >> expected exception was =E2=80=9CMetadataException: Unknown dataverse=
=E2=80=9D.
> >>
> >> Due to those reasons, if you are adding any new test cases, you will
> have
> >> to provide the following:
> >> 1. For each query in the test case, an expected result file (even
> queries
> >> that are expected to return no records).
> >> 2. For each expected exception in the test case, you have to provide t=
he
> >> complete exception type as well as the expected error message. If you
> have
> >> multiple expected exceptions in the same test case, they need to be
> ordered
> >> in the same order they will be raised.
> >>
> >> Unfortunately, currently we don=E2=80=99t have standard error codes fo=
r
> exceptions
> >> (e.g. ASX-0001: =E2=80=9CDuplicate key exception=E2=80=9D), so any cha=
nges to the
> >> exceptions messages will need to be reflected on the test cases, but
> this
> >> is better than having a broken test framework.
> >>
> >> Cheers,
> >> Murtadha
>
>

--089e013c65dcbfac6d052a5f57ed--