AssertionFailedError when running DRT

LabKey Support Forum (Inactive)
AssertionFailedError when running DRT Andy Straw  2012-05-09 12:11
Status: Closed
 
I'm trying to run the Developer Regression Test (DRT) as documented here: https://www.labkey.org/wiki/home/Documentation/page.view?name=checkin
I'm using 12.1, built from source, running on Windows 7. When I run "ant drt" in server/test/, I see the following:

...
14:56:31,011 =============== Completed BasicTest (1 of 5) =================

testSteps(org.labkey.test.tests.BasicTest)

junit.framework.AssertionFailedError: Asserts must be enabled to track memory leaks; please add -ea to your server VM params and restart.

at org.labkey.test.BaseSeleniumWebTest.checkLeaks(BaseSeleniumWebTest.java:1403)
...

Full log file is attached.

Which "server" is the error referring to? I assumed it meant tomcat, but I tried adding -ea to CATALINA_OPTS, as well as modifying catalina.sh to always use -ea on the java command line, and that didn't help. (I'm using cygwin - that's why I'm using catalina.sh, not catalina.bat.)

Please help. Thanks.

Andy Straw
University of Rochester
 
 
jeckels responded:  2012-05-09 14:10
Hi Andy,

Yes, this is referring to the Tomcat VM. If you're using catalina.sh/startup.sh to start the server, I'd expect that adding -ea to CATALINA_OPTS would be what's needed so I'm surprised that didn't work for you.

Instead of launching the test suite, you can also check to see if the -ea flag got picked up in the Admin Console. Under the "Runtime Information" header, check the value of "Asserts". It will say "enabled" if the server received the -ea flag.

Thanks,
Josh
 
Andy Straw responded:  2012-05-10 12:28
Thanks for the pointer to the Admin console info. I got past the "assertions not enabled" problem - was my bad (I had set CATALINA_OPTS in my .cshrc, but had not re-sourced that file from the shell where I was starting tomcat. And in catalina.sh, I had set -ea in the wrong Java command - I didn't notice there were several).

I ran into several other problems getting DRT to pass, but was able to use the assertion failure message and/or look at the stacktrace and source to figure out how to fix them. (had to set -DdevMode=true; modified source of BasicTest.java to allow Firefox/12, since that's what I'm running; had to configure site's Base Server URL to http://localhost:8080 - I had set it to http://<myhostname>.<mydomainName>:8080; had installed R, but had failed to configure it in LabKey).

I've now hit a failed assertion I'm not sure how to fix. But first, a question about running this suite of tests:

When I got this test failure, I notice that some test data that had been created didn't get cleaned up. For example, I see a couple of site users, a couple of site groups, a whole Study project and study folder with a bunch of data sets. Should I delete all these before re-running the tests, or does the test clean up before it re-runs?

Below is the failure I'm getting now (my instance is built from 12.1 source). Please advise. Thanks.

Andy Straw
University of Rochester

14:48:47,835 =============== Completed StudyTest (5 of 5) =================



testSteps(org.labkey.test.tests.StudyTest)

junit.framework.AssertionFailedError: Text 'AE-1:(VTN) AE Log' was not present 0 times. It was present 27 times

    at org.labkey.test.BaseSeleniumWebTest.assertTextPresent(BaseSeleniumWebTest.java:2491)

    at org.labkey.test.BaseSeleniumWebTest.assertTextPresent(BaseSeleniumWebTest.java:2473)

    at org.labkey.test.tests.StudyTest.verifyParticipantReports(StudyTest.java:145)

    at org.labkey.test.tests.StudyTest.doVerifySteps(StudyTest.java:109)

    at org.labkey.test.tests.StudyBaseTest.runUITests(StudyBaseTest.java:99)

    at org.labkey.test.tests.SimpleApiTest.doTestSteps(SimpleApiTest.java:77)

    at org.labkey.test.BaseSeleniumWebTest.testSteps(BaseSeleniumWebTest.java:1195)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)

    at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)

    at org.labkey.test.Runner.runTest(Runner.java:269)

    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:520)

    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1060)

    at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:911)



======================= Time Report ========================

BasicTest passed - 1:11 11%

SecurityTest passed - 2:15 20%

FlowTest passed - 3:17 29%

XTandemTest passed - 2:05 18%

StudyTest ERROR - 2:29 22%

------------------------------------------------------------

Total duration: 11:20
 
adam responded:  2012-05-10 12:51
You don't need to clean up after the tests. Every successful test cleans up what it creates, but unsuccessful tests (e.g., your study test) don't, to give us the ability to easily reproduce and investigate the problem. However, the first step of every test is to attempt to delete previously left artifacts.

I see this study failure myself when I run the tests, though the test runs fine on TeamCity and other developers' machines. It appears to be a timing issue with ExtJS quick filtering, perhaps related to recent Firefox releases. We will address this on the trunk soon, but of course you're welcome to investigate and propose a test fix if you want.

FYI: I enabled support for Firefox 12.0 on the trunk a few days ago.
 
Andy Straw responded:  2012-05-11 06:25
Thanks. I commented out the assertion that was failing, and now the whole DRT completes successfully. The test study and its project are cleaned up, but two site users and two site groups are left hanging around. I deleted them manually.

Andy