1

Trying to figure out what's the status of GWTTestCase suite/methodology.

I've read some things which say that GWTTestCase is kind of obsolete. If this is true, then what would be the preferred methodology for client-side testing?

Also, although I haven't tried it myself, someone here says that he tried it, and it takes seconds or tens of seconds to run a single test; is this true? (i.e. is it common to take tens of seconds to run a test with GWTTestCase, or is it more likely a config error on our side, etc)

Do you use any other methodology for GWT client-side testing that has worked well for you?

Andrei
  • 1,613
  • 3
  • 16
  • 36
  • Would love to see an answer to this. Tried GWTTestCase for the first time this week, and it does indeed take several seconds (30+) to start a trivial test. – Tony BenBrahim Jun 08 '17 at 02:07

1 Answers1

2

The problem is that any GWT code has to be compiled to run within a browser. If your code is just Java, you can run in a typical JUnit or TestNG test, and it will run as instantly as you expect.

But consider that a JUnit test must be compiled to .class, and run in the JVM from the test runner main() - though you don't normally invoke this directly, just start it from your build tool or IDE. In the same way, your GWT/Java code must be compiled into JavaScript, and then run in a browser of some kind.

That compilation is what takes time - for a minimal test, running in only one browser (i.e. one permutation), this is going to take a minimum of 10 seconds on most machines (the host page for the GWTTestCase to allow the JVM to tell it which test to run, and get results or stacktraces or timeouts back). Then add in how long the tested component of your project takes to compile, and you should have a good idea of how long that test case will take.

There are a few measures you can take to minimize the time taken, though 10 seconds is pretty much the bare minimum if you need to run in the browser.

  • Use test suites - these tell the compiler to go ahead and make a single larger module in which to run all of the tests. Downside: if you do anything clever with your modules, joining them into one might have other ramifications.
  • Use JVM tests - if you are just testing a presenter, and the presenter is pure Java (with a mock vide), then don't mess with running the code in the browser just to test its logic. If you are concerned about differences, consider if the purpose of the test is to make sure the compiler works, or to exercise the logic.
Colin Alworth
  • 17,801
  • 2
  • 26
  • 39
  • Well, I don't know what I expected. I guess I was looking for a magical solution or something. Yes, I know they are compiled in JS, etc; I just thought that maybe some more progress has been made in this direction. – Andrei Jun 09 '17 at 07:36
  • A better alternative is going to require a far faster compiler (which J2CL may bring us) while still traversing all classes that are needed, but to keep the test itself running quickly, it will still need to remove the unused code (and if you are writing unit tests, for any given test that ought to be most of your codebase...). The best progress I've made is to be thoughtful in what is being tested, what can be mocked, and where it can be run, etc - if you aren't poking the DOM in the tested code, you often don't need GWT. – Colin Alworth Jun 09 '17 at 16:03
  • I think it would be good idea to change "Use JVM tests" part to "Use MVP and JVM tests" and provide a link to gwt-mvp article (http://www.gwtproject.org/articles/mvp-architecture.html) so that people new either to MVP or GWT don't get confused ;) – morgwai Jun 12 '17 at 11:47