Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Upgrade to SmartGWT 4.0 cause test fail

    After migration to smartgwt 4.0, all gwt tests failed with:

    15:12:32,338 ERROR [com.gargoylesoftware.htmlunit.javascript.background.JavaScriptJobManagerImpl] - Job run failed with unexpected RuntimeException: TypeError: Cannot find function getBoundingClientRect in object [object HTMLDivElement]. (http://127.0.0.1:65226/com.app.TestAppJUnit.JUnit/sc/modules/ISC_Core.js#266)
    ======= EXCEPTION START ========
    Exception class=[net.sourceforge.htmlunit.corejs.javascript.JavaScriptException]
    com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot find function getBoundingClientRect in object [object HTMLDivElement]. (http://127.0.0.1:65226/com.app.TestAppJUnit.JUnit/sc/modules/ISC_Core.js#266)
    at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:601)
    at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
    at net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
    at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:499)
    at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:474)
    at com.gargoylesoftware.htmlunit.html.HtmlPage.executeJavaScriptIfPossible(HtmlPage.java:880)
    at com.gargoylesoftware.htmlunit.javascript.background.JavaScriptStringJob.runJavaScript(JavaScriptStringJob.java:50)
    at com.gargoylesoftware.htmlunit.javascript.background.JavaScriptExecutionJob.run(JavaScriptExecutionJob.java:84)
    at com.gargoylesoftware.htmlunit.javascript.background.JavaScriptJobManagerImpl.runJob(JavaScriptJobManagerImpl.java:226)
    at com.gargoylesoftware.htmlunit.javascript.background.JavaScriptJobManagerImpl.runSingleJob(JavaScriptJobManagerImpl.java:307)
    at com.gargoylesoftware.htmlunit.javascript.background.JavaScriptExecutor.run(JavaScriptExecutor.java:182)
    at java.lang.Thread.run(Thread.java:722)



    Finally in surefire-report I got this:

    Caused by: java.lang.Exception: com.google.gwt.core.client.JavaScriptException: (null): null
    at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java:248)
    at com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:136)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:561)
    at com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:269)
    at com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost.java:91)
    at com.smartgwt.client.bean.BeanFactory.exportSGWTModule(BeanFactory.java)
    at com.smartgwt.client.bean.BeanFactory.<clinit>(BeanFactory.java:344)


    I am using maven for project building and test execution. And everythings works well with smartgwt 3.x

    Here is my gwt-maven-plugin configuration:
    Code:
    <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>gwt-maven-plugin</artifactId>
                    <executions>
                        <execution>
                            <id>gwt-compile</id>
                            <phase>compile</phase>
                            <goals>
                                <goal>compile</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                        <runTarget>TestApp.html</runTarget>
                        <hostedWebapp>${war.directory}</hostedWebapp>
                        <webappDirectory>${war.directory}</webappDirectory>
                        <extraJvmArgs>-Xms512M -Xmx1536M</extraJvmArgs>
                        <optimizationLevel>4</optimizationLevel>
                        <localWorkers>4</localWorkers>
                        <logLevel>INFO</logLevel>
                        <mode>htmlunit</mode>
                        <draftCompile>true</draftCompile>
                        <warSourceDirectory>src/main/webapp</warSourceDirectory>
                        <debugPort>8001</debugPort>
                    </configuration>
                </plugin>

    #2
    Don't use HTMLUnit, it's not a real browser, so it will give spurious failures like this when SmartGWT uses standard DOM capabilities that are present in real browsers. Use Selenium instead - see the Automated Testing overview for details.

    Comment


      #3
      And we actually using Selenium for UI testing.

      However, you should understand the difference between unit and integration testing. We can't use Selenium in CI process, and definitely any kind of unit (even htmlunit) better the no unit.

      I am understand this problem is more related to htmlunit (and actually fixed in 2012), but from my perspective 3.x is better then 4.x.
      Last edited by shupakabras; 30 May 2013, 08:20.

      Comment


        #4
        It doesn't matter what kinds of tests you're running, using HTMLUnit is going to give you false results, so that's a bad practice.

        Comment


          #5
          I see. If GwtTestCase is not supported thats ok, I just need to know all my options.
          I assume this document http://www.smartclient.com/smartgwtee-latest/javadoc/com/smartgwt/client/docs/AutomatedTesting.html
          is not actual any more for 4.x.

          Comment


            #6
            Why would you say that? That document makes every effort to steer you away from HTMLUnit, just as we do here on the forums.

            Comment


              #7
              Well, we already say that tests *are expected to fail* under HtmlUnit because it's not a real browser, but we've now added a sentence to make it clear that, when that happens, we have no intention of trying to work around HtmlUnit issues: "In particular, if a test fails under HtmlUnit but would not fail in a real browser, this will not be regarded as a bug"

              If you choose to use HtmlUnit despite all these issues, be prepared to modify any failing test to run under Selenium instead.

              But again our recommendation, and what we do at HQ, is to run *all* tests, including unit tests, in a real browser.

              Comment

              Working...
              X