Split code into multiple artefacts

[backuitist]

Currently all the matchete code lives in a single jar with a few optional dependencies.
In order to have a lighter matchete we'd like to split this code in the following artefact:

• matchete-core: no dependencies (a good candidate for scala.js).
• matchete-junit
• matchete-json
• matchete-xml

[backuitist]

I'm quite new to scala.js, but I'm planning to test matchete-core with JUnit. Is this a problem for cross-publishing to scala.js?

[sLite]

As discussed by mail i'm happy to help out bringing matchete to scala.js :)

I'm also quite new to scala.js, but as far as my research goes, JUnit could only be used to test the version compiled for the JVM.
As JUnit doesn't cross-compile to javascript (and probably never will, as it's source is java, not scala), testing the javascript version isn't possible with it.

The tests for the javascript artifacts have to run within a JS environment (Rhino or node.js) to ensure that the output of the scalajs-compiler does what it should. Thus the tests need to be written for a testing framework that can compile to javascript itself.

So either all the tests need to be ported to a testing framework that plays well with scala.js or we would need different testsuites for both versions.

[backuitist]

Ok, thanks for the explanations, that makes sense. Maybe an option for cross testing would be to develop a small scala.js junit runner. It shouldn't be too hard as matchete only use @Test annotations. What do you think?

[sLite]

Somehow i don't like the idea to make a pseudo junit runner that implements org.junit classes, which it would have to for the imports to resolve...

[backuitist]

I may have missed something, but it seems to me that the only thing you need to have is an @Test annotation. I believe you could easily implement a uTest runner that is aware of that annotation.

Now if you're willing to move the tests from JUnit to uTest, that is fine by me, I'll accept a pull request :)

[sLite]

Yea, but the @test annotation still needs an import.

import org.junit.Test

Which is not resolvable by the scalajs-compiler when compiling the tests because there is no JUnit for scala.js

I'll give it a try today evening, starting from your new branch. :)

[backuitist]

Great!

Back to JUnit, just for the record, you can easily add (manually) that one annotation in your source code without having to drag the whole of junit.

[sLite]

Update from my side.

I ported all tests to utest and they pass on the JVM, which is nice.

But trying to run them on JS fails horribly. Digging into the source of the matchers, there is actually a lot of of reflection magic going on which is not supported by scala.js.

I will have a deeper look into this in the next days when i got some time at hand, but i doubt it's possible to bring matchete to scala.js with all the features it currently has.
As it looks now, it would even be necessary to break existing matchers, because things like beA are probably not going to work for cross-compilation any time soon.

[backuitist]

Right. I guess we should split the core further and move reflection based matchers to another module: core-reflect, which junit would depend on.
Thanks for your work!

[sLite]

I'm going finish my work on the utest migration and push that to github so you can take a look at it check if you feel fine with the change from JUnit to utest.

I'm going to start the separation of reflection based stuff after that. But i fear that there is some stuff that needs to be rewritten for the new core, because as far as i monitored yesterday, some very basic matchers (f.ex. beEqual for numbers) also use reflection through Diffable.

So this is probably going to take a while.

[backuitist]

Perfect. I'll take a look.
Diffable is a type class that is mostly implemented by implicit macros. As far as I know macros are a viable option for scala.js.

[sLite]

Yea, macros should work fine.
I guess the whole thing shouldn't take me more than a few days, depending on how much time i can spare :)

[backuitist]

Based on your utest migration I can do the reflection split if you want :)

[sLite]

Ok, let's see, in that case it might help if i do the crossProject setup for sbt so we can actually build and try to run the tests on the scalajs version.
I'll keep you updated :)

[backuitist]

Yep that would be ideal!

[backuitist]

Hi @sLite, how is it going?

[sLite]

I had a lot of stuff to do away from the computer, but i think i should be able to push stuff out today evening.

[sLite]

I've ported all the tests to utest and AssertMatchers (to get out the JUnit dependency).
build.sbt is changed to crossBuild scalajs (jvm tests pass, js already fails at the compiler due to reflection). This is most likely not going to be the final version, but it does what it needs to do for now.

What i can tell you so far:

• Class.getCanonicalName is not supported -> Class.getName is
• Class.isAssignableFrom looks a bit shallow in the ScalaJS Class implementation (https://github.com/scala-js/scala-js/blob/master/javalanglib/src/main/scala/java/lang/Class.scala#L31)
  Haven't tested, but this might also be source for some additional work.
• Class.instanceOf might also need some checking
• Reflection in general is not supported.
• Build output is somewhat messy, tests and builds seem to execute in parallel and the outputs interleave each other.

Take a look and experiment with utest and decide if you wan't to use it in the future. The ScalaJS space is a fast living system at the moment and it might be that utest is gone for good in some months from now.

check out https://github.com/sourcy/matchete/tree/tests-to-utest, i can open a pull request if you wan't to pull the changes to your repo.

To be honest, i don't know if it's worth the effort to pull apart the bits and parts of matchete to get it cross compiling to ScajaJS. But that's up to you to decide now ;)

[backuitist]

Thanks for that! I took a look at your branch. I need more to time to fiddle with ScalaJS, but it's true that I feel like stepping backward with uTest. I like my jUnit tests ;) The integration with the IDE sucks.
I'll give it more thought tomorrow.

[backuitist]

Hi @sLite,
Sorry for the delay!
As you can see I've done the split we were talking about at the beginning but I don't want to use uTest. The lack of IDE integration is a show stopper for me.
What I can imagine now is either a ScalaJS jUnit runner or, as you suggested, a separate project with a port of backuity tests to uTest. Then I'm fine with releasing 2 flavors of matchete-core:

• matchete-core
• matchete-core-reflect (matchers that require reflection or fancy scala features that are not supported by ScalaJS)

[sLite]

Hi,

Regarding IDE Integration, utest has working integration for me on a SBT project in IntelliJ 14.
But i can understand that you want to stick to JUnit.

I'm currently working on a different project, i will give the matchete ScalaJS port more thought when i have some time at hand within the next weeks.

A quick google search brought up this: https://github.com/nicolasstucki/scala-js-junit
Looks like we might get a junit runner for free ;)

[backuitist]

Perfect, I'll give scala-js-junit a try!

I'm on Intellij 14 too and the integration isn't great (yet) IMO:

1. you cannot run a specific test (Ctrl+Shift+F10 does not work for me)
2. you cannot list tests from within a class, with JUnit you get it for free by listing the methods