FileDiffSuite should be published along with lms

[manojo]

Given that it is the standard way of testing generated code, it makes sense that FileDiffSuite is available to everyone who uses LMS. As in general it is bad practice to publish test folders and files, I suggest having a test-utils package to which FileDiffSuite belongs.

[TiarkRompf]

Good idea. It would also be good to (1) update this to something that doesn't produce deprecation warnings and (2) harmonize it with the tutorial repo.

But unfortunately we can't just put FileDiffSuite into the main (i.e. non-test) source tree because that would introduce a dependency on scala-test from the main sources, which also seems like bad practice.

[manojo]

Good point. At the moment, even the current lms build should be changed for not depending on scalatest though. Looking here we see the dependency. We should indeed add an extra % "test" for the right scope:

libraryDependencies += ("org.scalatest" % "scalatest_2.11" % "2.2.2" % "test")

A possibility would be to create a separate project for testutils, which the main sources would depend on. Something along the following lines.

Removing deprecation warnings seems not too hard. It's about extending Spec instead of Suite and adding specific whitespaces in methods we want to be tested, as per the documentation.

[manojo]

Ideally, of course, we'd much rather use partest, but it currently does not support virtualized-2.11 IIRC.

[TiarkRompf]

A testutils package seems like a good idea once we have things like e.g. random testing (which @GeorgOfenbeck is working on) but just for FileDiffSuite it seems a bit heavyweight.

My suggestion would be to try and see if the relevant bits of FileDiffSuite can be factored out into a utility class that does not depend on ScalaTest. I think the tutorial repo almost does this.

Good point about the % test. Send a PR?