Adding tests to scalac

Hi Grzegorz,
I think you could use the -Xprint:<phase> option. Partest should read test files from the <test>.flags file, compile your test using compiler args in this file, compare the output to the <test>.check file.
Thus (untested):
under test/files/run, create files like
someGwtTest.scala // must contain a runnable Test object -- you can also create a someGwtTest directory with several source files, named as you like someGwtTest.flags // contents is spliced into scalac's argument listsomeGwtTest.check // compared to the output of compiling and running the test
hthadriaan

On Mon, Aug 16, 2010 at 5:59 PM, Grzegorz Kossakowski <grek@google.com> wrote:

Hi,

While working on my project[1] I'd like to add unit tests that check
the output of scala compiler.

Specifically, I'd like to have list of scala files that would be
compiled with my custom target ("target:jribble") and I'd like to
check if jribble files scalac generated match ones I provide.

I'm wondering how I could leverage existing testing infrastructure for
my task. I guess that all functionality I need: compiling files with
custom target, checking the output against provided files is already
implemented in partest. Could you give me some pointers where I should
be looking to achieve what I need? Maybe some existing tests?

[1] http://scalagwt.gogoego.com/

--
Best regards,
Grzegorz Kossakowski

On Mon, Aug 16, 2010 at 1:55 PM, Adriaan Moors wrote:
> Hi Grzegorz,
> I think you could use the -Xprint: option. Partest should read test
> files from the .flags file, compile your test using compiler args in
> this file, compare the output to the .check file.
> Thus (untested):
> under test/files/run, create files like
> someGwtTest.scala // must contain a runnable Test object -- you can also
> create a someGwtTest directory with several source files, named as you like
> someGwtTest.flags // contents is spliced into scalac's argument list
> someGwtTest.check // compared to the output of compiling and running the
> test

Hi Adriaan,

This is a nice way but I guess it doesn't scale very well. I'll be
having lots of jribble tests so I guess it makes sense to introduce
separate jribble directory where I'd be putting just scala input files
and expected jribble output files.

The rest should be handled automatically by partest. I've already
looked into it's implementation and, although it's not the cleanest
piece of scala code I've seen I guess I can hack it to do what I want.

If I fail I'll try your method...