JUnit tests without Generators
141 views
Skip to first unread message
Colin Alworth
Jan 26, 2018, 3:02:27 PM1/26/18
to GWT Contributors
As we look at how to keep migrating GWT provided user modules to modern best practices, the JUnit runner is a hairy one - it relies on a lot of the practices we discourage, including a great many modules in GWT that we might prefer it not use. It also assumes
As has been discussed on other lists, Google has an internal APT-based JUnit runner that presumably emits some Java and/or JS to enable some JS-based test running tools to iterate through the required tests and notify the user of failing code, including hints as to why it failed, with stack traces, etc. It has been previously discussed that this might be something that could be shared in whole or in part with the open source community, time permitting.
Is this still in the cards? Can any aspects of this implementation be discussed ahead of time so we can prepare our own tests for it? For example, does it use JUnit 4, and if so, can it use Rules, or just before/after methods?
--
Along similar lines, I did some work last fall to try to get JUnit 5 tests to work in a browser, but stopped shortly after working out how to replace the Engine with one that could in theory hand off control to a browser, and report back when complete. My idea was that if the JVM could dictate which tests were available to run, then JUnit 4 emulation could work, and JUnit 5 wiring would just ask our custom engine to transpile and run those tests, and report back all results in the familiar junit xml, with the expected build tool and IDE integration. This still might be worth pursuing, perhaps in parallel with any work Google already has working and is able to share.
Thanks,
Colin
As has been discussed on other lists, Google has an internal APT-based JUnit runner that presumably emits some Java and/or JS to enable some JS-based test running tools to iterate through the required tests and notify the user of failing code, including hints as to why it failed, with stack traces, etc. It has been previously discussed that this might be something that could be shared in whole or in part with the open source community, time permitting.
Is this still in the cards? Can any aspects of this implementation be discussed ahead of time so we can prepare our own tests for it? For example, does it use JUnit 4, and if so, can it use Rules, or just before/after methods?
--
Along similar lines, I did some work last fall to try to get JUnit 5 tests to work in a browser, but stopped shortly after working out how to replace the Engine with one that could in theory hand off control to a browser, and report back when complete. My idea was that if the JVM could dictate which tests were available to run, then JUnit 4 emulation could work, and JUnit 5 wiring would just ask our custom engine to transpile and run those tests, and report back all results in the familiar junit xml, with the expected build tool and IDE integration. This still might be worth pursuing, perhaps in parallel with any work Google already has working and is able to share.
Thanks,
Colin
Goktug Gokdogan
Jan 26, 2018, 3:25:42 PM1/26/18
to google-web-toolkit-contributors, dankurka, Julien Dramaix
+dramaix +dankurka
It doesn't support runners nor rules; just the basic stuff.
@dramaix: Let's release the source of J2CL junit emulator under the J2CL repo. We don't need to wait until it works for bazel.
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7ecb26e6-e315-4e99-a89f-29a1a1a3c1b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thomas Broyer
Jan 26, 2018, 5:59:21 PM1/26/18
to GWT Contributors
Correct me if I'm wrong, this is relying on JUnit 4 suited to generate appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, possibly simply TestCase), with a "new" emulation of those classes based on JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3 to find test, setup, teardown methods/functions by naming rules)
Goktug Gokdogan
Jan 26, 2018, 10:17:39 PM1/26/18
to google-web-toolkit-contributors
Yes, that's correct.
It is a simple system with two part generation.
First part in bazel that generates an empty java class with a class annotation that points to JUnit suite to trigger APT.
The second part in APT that generates the wrapper around junit3/junit4 tests that are listed in the suite to export test function to the global scope (as the javascript framework expects).
There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to compile or make things look like regular JVM test. End result is a pure javascript suite executed by a javascript test framework driver.
On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer <t.br...@gmail.com> wrote:
Correct me if I'm wrong, this is relying on JUnit 4 suited to generate appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, possibly simply TestCase), with a "new" emulation of those classes based on JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3 to find test, setup, teardown methods/functions by naming rules)
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%40googlegroups.com.
Colin Alworth
Feb 15, 2018, 3:15:31 PM2/15/18
to GWT Contributors
Anything we can do to facilitate this? Also, if it is released under j2cl, is there an expectation that it could be factored out and made to work with GWT2, and released generally instead of just under J2CL (in its binaries and its deadlines)?
Goktug Gokdogan
Feb 16, 2018, 2:59:12 PM2/16/18
to google-web-toolkit-contributors
I haven't thought about separating it from J2CL, not sure if it is a good idea.
Why do you need it for GWT2? For code sharing, we simply use Junit3 style and we didn't feel much pain about it.
On Thu, Feb 15, 2018 at 12:15 PM Colin Alworth <nilo...@gmail.com> wrote:
Anything we can do to facilitate this? Also, if it is released under j2cl, is there an expectation that it could be factored out and made to work with GWT2, and released generally instead of just under J2CL (in its binaries and its deadlines)?
On Friday, January 26, 2018 at 9:17:39 PM UTC-6, Goktug Gokdogan wrote:
Yes, that's correct.It is a simple system with two part generation.First part in bazel that generates an empty java class with a class annotation that points to JUnit suite to trigger APT.The second part in APT that generates the wrapper around junit3/junit4 tests that are listed in the suite to export test function to the global scope (as the javascript framework expects).There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to compile or make things look like regular JVM test. End result is a pure javascript suite executed by a javascript test framework driver.
On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer <t.br...@gmail.com> wrote:
Correct me if I'm wrong, this is relying on JUnit 4 suited to generate appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, possibly simply TestCase), with a "new" emulation of those classes based on JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3 to find test, setup, teardown methods/functions by naming rules)
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/daeccad3-886f-4fda-801d-694c3d4f19d3%40googlegroups.com.
Colin Alworth
Feb 16, 2018, 3:09:11 PM2/16/18
to GWT Contributors
Several things I'd like to achieve:
* I'd like to support JUnit 4 in GWT2 (well, I'd actually like to support JUnit 5 in both, but one step at a time) - JUnit 3 practically doesn't exist outside of GWT2.
* There are probably better ways to do testing than the existing junit shell wiring in GWT2, such as leveraging SDM to quickly make changes and re-run tests, finding other ways to serve content, avoiding generators and arcane servlet tags, etc. Adopting JUnit4 to replace the current generator in GWT2 gets part of that work done up front.
* Existing junit shell wiring has some annoying dependencies and needs a rewrite anyway if we are to continue migrating and updating official modules - even if we decide that JUnit 3 is superior to 4, and that recompiling without SDM is better in GWT2, we still can't (for example) properly unit test an updated I18n module which uses a system property named `locale` without running into issues with the existing I18n module, which the old junit wiring makes every test use (JUnit -> Logging -> LoggingDisabled -> UI, which includes basically everything else in gwt-user).
* I'd like to support JUnit 4 in GWT2 (well, I'd actually like to support JUnit 5 in both, but one step at a time) - JUnit 3 practically doesn't exist outside of GWT2.
* There are probably better ways to do testing than the existing junit shell wiring in GWT2, such as leveraging SDM to quickly make changes and re-run tests, finding other ways to serve content, avoiding generators and arcane servlet tags, etc. Adopting JUnit4 to replace the current generator in GWT2 gets part of that work done up front.
* Existing junit shell wiring has some annoying dependencies and needs a rewrite anyway if we are to continue migrating and updating official modules - even if we decide that JUnit 3 is superior to 4, and that recompiling without SDM is better in GWT2, we still can't (for example) properly unit test an updated I18n module which uses a system property named `locale` without running into issues with the existing I18n module, which the old junit wiring makes every test use (JUnit -> Logging -> LoggingDisabled -> UI, which includes basically everything else in gwt-user).
On Friday, February 16, 2018 at 1:59:12 PM UTC-6, Goktug Gokdogan wrote:
I haven't thought about separating it from J2CL, not sure if it is a good idea.Why do you need it for GWT2? For code sharing, we simply use Junit3 style and we didn't feel much pain about it.
On Thu, Feb 15, 2018 at 12:15 PM Colin Alworth <nilo...@gmail.com> wrote:
Anything we can do to facilitate this? Also, if it is released under j2cl, is there an expectation that it could be factored out and made to work with GWT2, and released generally instead of just under J2CL (in its binaries and its deadlines)?
On Friday, January 26, 2018 at 9:17:39 PM UTC-6, Goktug Gokdogan wrote:
Yes, that's correct.It is a simple system with two part generation.First part in bazel that generates an empty java class with a class annotation that points to JUnit suite to trigger APT.The second part in APT that generates the wrapper around junit3/junit4 tests that are listed in the suite to export test function to the global scope (as the javascript framework expects).There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to compile or make things look like regular JVM test. End result is a pure javascript suite executed by a javascript test framework driver.
On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer <t.br...@gmail.com> wrote:
Correct me if I'm wrong, this is relying on JUnit 4 suited to generate appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, possibly simply TestCase), with a "new" emulation of those classes based on JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3 to find test, setup, teardown methods/functions by naming rules)
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
Goktug Gokdogan
Feb 16, 2018, 7:39:15 PM2/16/18
to google-web-toolkit-contributors
The dependency issue could be solved separately in a much simpler change.
I agree improvements could be made for 2.8 testing but it is a big project and I think it might be more worthwhile to have 3.x sooner.
Anyway we can discuss this further after we release the source.
On Fri, Feb 16, 2018 at 12:09 PM Colin Alworth <nilo...@gmail.com> wrote:
Several things I'd like to achieve:
* I'd like to support JUnit 4 in GWT2 (well, I'd actually like to support JUnit 5 in both, but one step at a time) - JUnit 3 practically doesn't exist outside of GWT2.
* There are probably better ways to do testing than the existing junit shell wiring in GWT2, such as leveraging SDM to quickly make changes and re-run tests, finding other ways to serve content, avoiding generators and arcane servlet tags, etc. Adopting JUnit4 to replace the current generator in GWT2 gets part of that work done up front.
* Existing junit shell wiring has some annoying dependencies and needs a rewrite anyway if we are to continue migrating and updating official modules - even if we decide that JUnit 3 is superior to 4, and that recompiling without SDM is better in GWT2, we still can't (for example) properly unit test an updated I18n module which uses a system property named `locale` without running into issues with the existing I18n module, which the old junit wiring makes every test use (JUnit -> Logging -> LoggingDisabled -> UI, which includes basically everything else in gwt-user).
On Friday, February 16, 2018 at 1:59:12 PM UTC-6, Goktug Gokdogan wrote:
I haven't thought about separating it from J2CL, not sure if it is a good idea.Why do you need it for GWT2? For code sharing, we simply use Junit3 style and we didn't feel much pain about it.
On Thu, Feb 15, 2018 at 12:15 PM Colin Alworth <nilo...@gmail.com> wrote:
Anything we can do to facilitate this? Also, if it is released under j2cl, is there an expectation that it could be factored out and made to work with GWT2, and released generally instead of just under J2CL (in its binaries and its deadlines)?
On Friday, January 26, 2018 at 9:17:39 PM UTC-6, Goktug Gokdogan wrote:
Yes, that's correct.It is a simple system with two part generation.First part in bazel that generates an empty java class with a class annotation that points to JUnit suite to trigger APT.The second part in APT that generates the wrapper around junit3/junit4 tests that are listed in the suite to export test function to the global scope (as the javascript framework expects).There is no hybrid mode GwtTestcCase/JunitShell that tries to drive to compile or make things look like regular JVM test. End result is a pure javascript suite executed by a javascript test framework driver.
On Fri, Jan 26, 2018 at 2:59 PM, Thomas Broyer <t.br...@gmail.com> wrote:
Correct me if I'm wrong, this is relying on JUnit 4 suited to generate appropriate goog.testing code, JUnit 3 test cases (GWTTestCase basically, possibly simply TestCase), with a "new" emulation of those classes based on JsInterop to goog.testing, right? (goog.testing behaving similar to JUnit 3 to find test, setup, teardown methods/functions by naming rules)
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a083c6c4-43aa-44f0-a639-2eab1a12a2c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/daeccad3-886f-4fda-801d-694c3d4f19d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/afe40d9c-a652-413c-a776-e2a6df9bba15%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages