This is indeed a good improvement. Regarding this, I have a question. After
merging the current master into my branch, I executed "executionTest" in
Eclipse. And I found that "Failure Trace" stack trace in JUnit shows not
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 one
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:594)
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(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.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:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.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:
<STRING_LITERAL> ...
<IDENTIFIER> ...
==> text : string,
STACKTRACE:
at
org.apache.asterix.test.aql.TestExecutor.executeHttpMethod(TestExecutor.java:228)
at
org.apache.asterix.test.aql.TestExecutor.executeDDL(TestExecutor.java:329)
at
org.apache.asterix.test.aql.TestExecutor.executeTest(TestExecutor.java:430)
... 34 more
Best,
Taewoo
On Tue, Jan 12, 2016 at 12:46 PM, Murtadha Hubail <[email protected]>
wrote:
> Hi All,
>
> Last night Abdullah and I merged the Asterix test framework improvement
> change. So, don’t be surprised if you have a test case that worked
> 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 of
> the state the test framework was in. I encountered test cases that were
> 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” and it was considered as passing, even though the
> expected exception was “MetadataException: Unknown dataverse”.
>
> 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 the
> 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’t have standard error codes for exceptions
> (e.g. ASX-0001: “Duplicate key exception”), so any changes 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
