Thanks Erik!
Basically this is where a modular approach is best suited for testing.
You need to think about what you need to test in your "publisher"
program and how you can break it into pieces
BTW, the compiler is not doing much stuff different that that simple
FileNode request. :)
Mike
Quoting Erik de Bruin <e...@ixsoftware.nl>:
"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
