airspec: Callling scalaJsSupport is a bit verbose and confusing

To use airspec on Scala.js, is is required to invoke scalaJsSupport in test code.

https://github.com/wvlet/airframe/blob/9277263b0d507ea7459a12fef82d301395fd3463/airspec/src/test/scala/examples/TestSpec.scala#L24-L25

The reason is mentoined in below

https://github.com/wvlet/airframe/blob/master/docs/airspec.md This is because Scala.js has no runtime reflection to find methods in AirSpec classes, so we need to provide method data by calling scalaJsSupport. Internally this will generate MethodSurfaces (airframe-surface), so that AirSpec can find test methods at runtime. Calling scalaJsSupport has no effect in Scala JVM platform, so you can use the same test spec both for Scala and Scala.js.

I think this is…,

• A bit verbose.
  • Adding scalaNativeSupport when airspec support Scala Native ?
• Confusing for airspec beginner, specially when migrating from scalatest, which does not require extra step like scalaJsSupport.
  • Test code is succesfully compiled without scalaJsSupport, but no tests run at all !!
  • I spent several hours to figure out scalaJsSupport is required…

It would be great if scalaJsSupport is deprecated ang gone. Regarding “runtime reflection in Scala.js”, portable-scala-reflect might help.

Or, it may be OK if airspec warns like No test classes with scalaJsSupportfound. See https//.....

[xerial]

With #909, if no test case is found, a warning message will be shown. Actually some test cases of AirSpec itself were also missing scalaJsSupport 😅

[xerial]

Thanks. I agree that adding scalaJsSupport is a bit annoying. Personally, I’ve started using only test(…) method for Scala.js.

Two action items:

• Showing test(...) function first will be helpful for new users to avoid such confusion.
• Adding a warning message when scalaJsSupport is missing.