You don't need to test anything, I haven't committed them yet.
As far as asking about methods, what I added made sense and should
have made sense to you by them being overridable. I mean;
addLibraries(libraries)
addSourcePath(paths)
Should be pretty clear they were hooks to add sources and SWCs to
compile against.
Since we are generating JS we need context sometimes when producing
stuff like method scope, it's not a straight forward 'unit' test in
this case.
Mike
Quoting Erik de Bruin <e...@ixsoftware.nl>:
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
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
