GWTTestCase no "Dialog" object after switching from SmartGWT 6.1 to 13.0

[eliasbalasis]

We have been successfully running GWT Unit Tests using SmartGWT 6.1.

However, after switching to SmartGWT 13.0
we are experiencing the following error:

com.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot read property "Dialog" from undefined
    at com.smartgwt.client.util.I18nUtil.initMessages(I18nUtil.java:198)
    at com.smartgwt.client.util.I18nUtil.init(I18nUtil.java:32)
    at com.smartgwt.client.SmartGwtEntryPoint.$onModuleLoad(SmartGwtEntryPoint.java:517)
    at com.google.gwt.junit.client.GWTTestCase.$runBare(GwtTestGenerateJSONFilterCriteria.java:22)
    at com.google.gwt.junit.client.GWTTestCase.$__doRunTest(GWTTestCase.java:115)
    at com.google.gwt.junit.client.impl.GWTRunner.$runTest(GWTRunner.java:302)
    at com.google.gwt.junit.client.impl.GWTRunner.$doRunTest(GWTRunner.java:235)
    at com.google.gwt.junit.client.impl.GWTRunner$TestBlockListener.$onSuccess(GWTRunner.java:106)
    at com.google.gwt.junit.client.impl.GWTRunner$TestBlockListener.onSuccess(GWTRunner.java:100)
    at com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.$onResponseReceived(RequestCallbackAdapter.java:232)
    at com.google.gwt.http.client.Request.$fireOnResponseReceived(Request.java:250)
    at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:412)
    at Unknown.anonymous(XMLHttpRequest.java:329)
    at com.google.gwt.core.client.impl.Impl.apply(Impl.java:309)
    at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:368)
    at Unknown.anonymous(Impl.java:78)

[Isomorphic]

Are you using GWT Test Case with the HTMLUnit pseudo-browser? We wouldn't expect that to work - HTMLUnit is not a real browser, and we have not implemented special support for it (since this could only result in false negatives and false positives relative to real browsers, so there's little point).

Regardless, what this looks like is that some modules of the underlying SmartClient libraries (ISC_Core.js et al) have not been loaded. As your configured locale tries to apply messages to various components, this causes a crash.

[eliasbalasis]

I am not using this to test the UI itself but some APIs, the filter builder client-server flow in particular.

Here is the console output of the failing GWT Unit Test:

2022-05-06/19:39:58.996/BST [main] INFO org.eclipse.jetty.util.log - Logging initialized @2121ms
2022-05-06/19:39:59.093/BST [main] INFO org.eclipse.jetty.server.Server - jetty-9.2.14.v20151106
2022-05-06/19:39:59.524/BST [main] WARN org.eclipse.jetty.annotations.AnnotationConfiguration - ServletContainerInitializers: detected. Class hierarchy: empty
2022-05-06/19:39:59.735/BST [main] INFO org.eclipse.jetty.server.handler.ContextHandler - Started c.g.g.j.@47289387{/,file:/XXX/www-test/,AVAILABLE}{C:\XXX\www-test}
2022-05-06/19:39:59.751/BST [main] INFO org.eclipse.jetty.server.ServerConnector - Started ServerConnector@1c25b8a7{HTTP/1.1}{0.0.0.0:60764}
2022-05-06/19:39:59.751/BST [main] INFO org.eclipse.jetty.server.Server - Started @2881ms
Compiling module XXX.GenerateJSONFilterCriteria.JUnit
   Compiling 1 permutation
      Compiling permutation 0...
   Compile of permutations succeeded
   Compilation succeeded -- 8.769s
Linking into C:\XXX\www-test\XXX.GenerateJSONFilterCriteria.JUnit
   Link succeeded
   Linking succeeded -- 4.819s
Starting http://localhost:60764/XXX.GenerateJSONFilterCriteria.JUnit/junit.html on browser FF38
log4j:WARN No appenders could be found for logger (com.gargoylesoftware.htmlunit.WebClient).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/junit.html (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/XXX.GenerateJSONFilterCriteria.JUnit.nocache.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/F534A773CCB57381BA6B1FF89CBAC062.cache.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Core.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Foundation.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Containers.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Grids.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Forms.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_DataBinding.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_RichTextEditor.js (127.0.0.1)
200 - GET /XXX.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Calendar.js (127.0.0.1)
200 - POST /XXX.GenerateJSONFilterCriteria.JUnit/junithost (127.0.0.1) 262 bytes
logging for HtmlUnit thread
   [ERROR] Alert: Core SmartClient JavaScript libraries appear not to be loaded. If inheriting the NoScript SmartGWT modules, verify that the HTML file includes <script src=...> tags to load the SmartClient module .js files from the appropriate location within the WAR. By default these files are present under [GWT app name]/sc/modules/.
200 - POST /XXX.GenerateJSONFilterCriteria.JUnit/junithost (127.0.0.1) 238 bytes
   [ERROR] Alert: Core SmartClient JavaScript libraries appear not to be loaded. If inheriting the NoScript SmartGWT modules, verify that the HTML file includes <script src=...> tags to load the SmartClient module .js files from the appropriate location within the WAR. By default these files are present under [GWT app name]/sc/modules/.
200 - POST /XXX.GenerateJSONFilterCriteria.JUnit/junithost (127.0.0.1) 239 bytes
   [ERROR] Alert: Core SmartClient JavaScript libraries appear not to be loaded. If inheriting the NoScript SmartGWT modules, verify that the HTML file includes <script src=...> tags to load the SmartClient module .js files from the appropriate location within the WAR. By default these files are present under [GWT app name]/sc/modules/.

The same kind of test with same structure works with SmartGWT 6.1

[Isomorphic]

Notice that last alert. Same thing we just told you.

[eliasbalasis]

I know the modules haven't been loaded, my question is why.

But, I have figured out in the meantime that the problem lies with use of "new SmartGwtEntryPoint().onModuleLoad()" on "gwtSetUp()" method of "GWTTestCase", which was required on SmartGWT 6.1 to make use of certain client-side APIs within the test, "com.smartgwt.client.data.AdvancedCriteria" in particular.

The same initialization doesn't work with SmartGWT 13.0

If you cannot explain this then my alternative would be transforming my tests to make use of captured JSON filter content instead of com.smartgwt.client.data.AdvancedCriteria".

I hope this helps you better.

[Isomorphic]

Sorry, we thought that since you already had a project you knew your options around module loading.

See the “Debugging” overview for instructions here: it covers the different modes you can run in (Classic Hosted Mode vs SuperDevMode) and options around module loading.

Just to note, this is not a backcompat issue with SmartGWT - what’s happened here is just that during the upgrade you overwrite some config - maybe your host .html file or a GWT module file - happens all the time.

[eliasbalasis]

I fear the best way to reproduce the problem is creating a little dedicated project and share it with you for deeper study.
Please wait, as soon as I have this ready I will send you the project link and instructions to reproduce the problem.

[eliasbalasis]

Can you pleasse provide the "Debugging Oerview" link ? it is missing from your last reply.

[Isomorphic]

It wasn't missing - with any similar reference, Google will take you right to it (first hit for "smartgwt debugging overview", for example), or, just look in com.smartgwt.client.docs, which is where all the overviews are (covered in the QuickStart).

https://smartclient.com/smartgwtee-l...Debugging.html

[eliasbalasis]

Finally, after capturing HtmlUnit logging, the deepest error is the following:

[INFO] 2022-05-09/09:25:57.563/UTC [htmlUnit client thread] ERROR com.gargoylesoftware.htmlunit.javascript.StrictErrorReporter - error: message=[syntax error] sourceName=[http://localhost:41508/com.nielsen.book.poc_shared.gwt.smartgwt.GenerateJSONFilterCriteria.version.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Core.js] line=[567] lineSource=[return _3},isc.A.getValueIndexMap=function isc_Arra_getValueIndexMap(_1){if(Object.fromEntries){return Object.fromEntries(this.$1876((entry,index)=>[entry[_1],index]))}] lineOffset=[149]
[ERROR] Exception in thread "htmlUnit client thread" ======= EXCEPTION START ========
[ERROR] Exception class=[net.sourceforge.htmlunit.corejs.javascript.EvaluatorException]
[ERROR] com.gargoylesoftware.htmlunit.ScriptException: syntax error (http://localhost:41508/com.nielsen.book.poc_shared.gwt.smartgwt.GenerateJSONFilterCriteria.version.GenerateJSONFilterCriteria.JUnit/sc/modules/ISC_Core.js#567)

and it does feel related to compatibility.

I have created a small Maven project which reproduces the problem accurately, but I am reading that Maven projects and ZIP attachments are not considered valid test cases.
How are you expecting us to demonstarte the problem if we are not allowed to attach a test case ?

[Isomorphic]

When you go to post, there is an extensive explanation of why .zips are not allowed, and what to do about it. Basically, test cases should be minimal, ready to be dropped into a standard environment, so that it is not necessary to inspect every possible misconfiguration in your project when Support goes to look at a claimed bug. In the exceedingly rare case where a full project is appropriate, you can stick a .zip onto Dropbox or email it.

Here, we do not need a test case anyway. As we covered, HTMLUnit is not a real browser, and that's why we tell people not to use it. It looks like HTMLUnit is failing to parse JavaScript that is valid in real browsers.

There's a chance this has to do with some "arrow syntax" functions which briefly existed in 13.0 and were removed to maintain compatibility with very old browsers, so, updating to the latest build might fix this.

If not, sorry, this will not be investigated. We explicitly recommend against GWTTestCase+HtmlUnit in our docs for exactly this reason, and we explicitly say problems with HtmlUnit will not be considered bugs:

Note that running tests under HtmlUnit can lead to false failures in a variety of areas, including network communication and XML processing, where HtmlUnit's behaviors do not correspond to any real browser. Note that, if you find that a test fails under HtmlUnit but would not fail in a real browser, this will not be regarded as a SmartGWT bug.

If you use GwtTestCase at all, Isomorphic recommends that the majority of your tests are executed using the runStyle option that allows GwtTestCase to run under a real browser via Selenium.

https://smartclient.com/smartgwt-6.0...edTesting.html

If you desperately want to keep these test cases alive, you have a couple of options:

1. use runStyle to run in a real browser, as the docs recommend

OR

2. engage Isomorphic Consulting in an hourly project to try to try to solve whatever is wrong with HtmlUnit (note that in this case, while we'll solve the problem, HtmlUnit will continue to not be supported, per docs).

[eliasbalasis]

Thanks, this makes sense now.
I understand the reasons why HtmlUnit is not supported as well as the reasons for which uploading of test cases is not allowed, excluding rare exceptions of course.
I will try with the latest version of SmartGWT 13 and if this still doesn't work I will use the "runStyle" option as suggested, even though it would greatly complicate the testing effort.

[eliasbalasis]

I have finally managed to make this work, by running tests using production mode rather than development (a.k.a. hosted) mode and also ignoring the recommended "new SmartGwtEntryPoint().onModuleLoad()" initialization.

The lesson learned is that, contrary to my natural expectation, JavaScript code of SmartGWT doesn't seem to be not always friendly with headless browsers like HtmlUnit, which can complicate testing effort.

You can now archive this case.

[eliasbalasis]

FYI, 13.0-p20220511 seems to be working.

[Isomorphic]

Glad it's working for you.

Just to reiterate, SmartGWT is designed to run in real browsers, so testing needs to be done in real browsers as well, or false negatives and false positives may result, which defeats the purpose of testing.

While it seems that HtmlUnit is working for now, maintaining compatibility with HtmlUnit is not a design goal of ours, and it appears that HtmlUnit does not support JavaScript syntax that is valid for over 99% of global browsers, and which we plan to begin using within 2 years at the latest.

If HtmlUnit isn't upgraded, your test cases will break at that time, so we would recommend planning a transition to test in real browsers (via runStyle, or via Selenium).

Please note also that this is not a general "headless browser" problem (the majority of the SmartClient runtime can actually be run server-side under Node/V8), it's a problem with HtmlUnit.