"Reverted" the removal of the two methods. All should be well now.
I didn't really want to functional test the compiler (for now), I was just asking if it was a good idea to have the implemenation in the tests and the implementation in the MXMLJSC be so different. But since you've clearly thought that through, I'll leave well enough alone. Any suggestions what might be the best way to test a "project", i.e. a set of file that have internal dependencies, like a base class and several subclasses, or a main project file and some components? This seems to require more than just strings of code, as the compiler needs to be aware of the dependencies (like it currently needs to be fed the spark.swc etc.). Do you think it's best to create a new TestBase that uses the same approach as the "actual" compiler, or something else? Thanks, EdB On Tue, Feb 12, 2013 at 7:56 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: > Those AMD test are local, not yet committed? I cannot test what isn't there... > > EdB > > > > On Tue, Feb 12, 2013 at 7:54 PM, Michael Schmalle > <apa...@teotigraphix.com> wrote: >> I guess I have to stick my foot in my mouth on this. >> >> I see you didn't actually implement the compiler yet. So I will stand by >> what I just said that changing this is bad so don't do it (future tense). >> >> But you did clobber a commit I made a day or two ago. This is making AMD >> tests I have broken. >> >> I will add the methods back if you are done working on the TestBase class. >> >> If you want to functional test the compiler, make a new test base. >> >> 1443539 commit. >> >> Mike >> >> >> >> Quoting Michael Schmalle <apa...@teotigraphix.com>: >> >>> Hi Erik, >>> >>> Yes, this was a bad move. The way the TestBase was setup was testing >>> 'unit's of code, thus we are using a simple setup for config and a simple >>> AST syntax request to get a FileNode. >>> >>> You need to change it back, what you changed it to is a 'functional' test. >>> We are not testing functionality of the compiler. >>> >>> By doing what you did, you introduced variance to the tests. The way the >>> TestBase was setup was a very simple load, parse, return the node. >>> >>> Also, I don't think you didn't an SVN update did you? I added two methods >>> that allowed the sub classes to added libraries and source paths to the >>> configuration. addLibraries(), addSourcePath() >>> >>> Can you please revert? >>> >>> Thanks, >>> Mike >>> >>> >>> Quoting Erik de Bruin <e...@ixsoftware.nl>: >>> >>>> Hi Mike (I guess ;-)), >>>> >>>> I was poking around the FalconJx unit tests to set up the testing of >>>> projects (tests made up of more than one (generated) file), and I >>>> noticed that the tests "roll their own" implementation of the >>>> compilation process. It's generally the same, but some differences >>>> exist. While trying to get the project testing going, I thought I'd >>>> refactor MXMLJSC in such a way that it can be used for unit testing as >>>> well. I thought this might increase the reliability of the unit tests, >>>> as they would always test the compilation implementation that is >>>> actually used by FalconJx. Is that a really bad idea? >>>> >>>> EdB >>>> >>>> >>>> >>>> -- >>>> Ix Multimedia Software >>>> >>>> Jan Luykenstraat 27 >>>> 3521 VB Utrecht >>>> >>>> T. 06-51952295 >>>> I. www.ixsoftware.nl >>>> >>> >>> -- >>> Michael Schmalle - Teoti Graphix, LLC >>> http://www.teotigraphix.com >>> http://blog.teotigraphix.com >>> >>> >> >> -- >> Michael Schmalle - Teoti Graphix, LLC >> http://www.teotigraphix.com >> http://blog.teotigraphix.com >> > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
