Testing EnsoMeta ability to load Enso types from Standard.Base

[JaroslavTulach]

Pull Request Description

• comments in Run Standard.Google in dual JVM mode #14040 indicates
• a need for std-bits to be tested with @Rule ContextUtils
• e.g. run quickly as JUnit tests
• allow access to Enso runtime while running the tests

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  Java,
• Unit tests have been written where possible.

[JaroslavTulach]

@jdunkerley, it is possible to run these tests quickly:

sbt:enso> std-tests/clean
sbt:enso> std-tests/test
[info] Test run org.enso.base.polyglot.tests.EnsoMetaTest finished: 1 total, 3.595s
[info] Passed: Total 1, Failed 0, Errors 0, Passed 1

e.g. the test finished in less than four seconds (or in eleven seconds on CI).

[JaroslavTulach]

• originally I wanted to add these tests into std-table
• but there is recursive project dependency
• as test-utils depend on std-table (to have Enso distribution fully built)
• and making std-table depend on test-utils was ... complicated...

[JaroslavTulach]

To debug:

• but breakpoint on line 23
• let your IDE listen to port 5005
• invoke following in the sbt

sbt:enso> project std-tests
sbt:std-tests> withDebug --debugger testOnly -- *EnsoMetaTest

• does it work for you @jdunkerley, @AdRiley?

[Akirathan]

What is the difference between std-tests and runtime-integration-tests? In runtime-integration-tests, we are already doing from Standard.Base import all, for example in VectorSortTest. Why yet another project?

EDIT: std-tests uses stuff from std-base. That is the difference.

[JaroslavTulach]

What is the difference between std-tests and runtime-integration-tests? In runtime-integration-tests, we are already doing from Standard.Base import all, for example in VectorSortTest. Why yet another project?
std-tests uses stuff from std-base. That is the difference.

• The difference is mostly psychological
• When talking to @jdunkerley I realized the library guys never execute runtime-integration-tests
  • very likely they don't consider those tests to be "their" business
  • they had no idea of ContextUtils and the possibilities it opens when JUnit testing Enso code
• as a result of that they were putting artificial constrains on their code in std-base, std-table, etc.
• thus I decided to demonstrate how to write JUnit tests in a std-bits/* namespace
• e.g. in a space that they are not afraid to use

Thus your question is correct, @Akirathan. You, me would put such kind of a test into runtime-integration-tests. Duplicating the infrastructure in std-bits/std-tests has no technical reasons, but it will hopefully remove the psychological barrier for the libraries team to write such tests as well.

[JaroslavTulach]

• I'd like to start using this infrastructure for writing tests in Arrow like storage over ByteBuffer to allow dual JVM buffer exchange #14309

[jdunkerley]

Happy with this approach for when we need to test the back and forth.