You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2013/02/12 19:16:46 UTC
[FalconJx] TestBase not using 'actual' compile method from MXMLJSC
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
Re: [FalconJx] TestBase not using 'actual' compile method from
MXMLJSC
Posted by Michael Schmalle <mi...@teotigraphix.com>.
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 <er...@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 <er...@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
>> <ap...@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 <ap...@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 <er...@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
>
Re: [FalconJx] TestBase not using 'actual' compile method from MXMLJSC
Posted by Erik de Bruin <er...@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 <er...@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
> <ap...@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 <ap...@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 <er...@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
Re: [FalconJx] TestBase not using 'actual' compile method from
MXMLJSC
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I understand clear as mud, that is exactly what it was to you. My
point is that sometimes when I am creating things from scratch as in
AMD, I am not going to commit it right off the bat because I don't
want to be moving files around and doing a bunch of nosensical
commits, that is the way I work.
I am doing nothing in AMD that you could break other than you changing
visitor methods or something, which I think we can both agree we
wouldn't do unless we made all the "current" tests pass. That is what
I did on a couple of my commits but, I made the tests pass.
The point of unit testing is that you can develop somethings off line
and they "shouldn't" have a direct dependency on what you are working
on for the tests or for that matter anything under a current unit
test. This is the case with the AMD and another reason I designed the
emitter and visitor framework the way I did, so it's really modular
and unobtrusive.
Anyway, the AMD is no different than what you are working on other
than the fact I need to create a temp StringBuilder that could be used
when using write() so I could replace dependencies at the end.
There is no more state than anything else, so it's what you hoped.
I am probably going to commit the rest of that code and tests in a day or two.
I am not clear on when I can get back to MXML. I am currently working
on something that is taking a bit of time. Like I said, with this
project as it stands I am more concerned about JS being compiled as
business logic first, I have said that from the beginning.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Just to clarify some stuff, since this is my "first day back on the
> job after a week long sick leave which was supposed to a ski vacation"
> (and I'm a bit cranky still as a result... I really shouldn't be in
> public) and I need to get back up to speed on our lovely project:
>
>> You don't need to test anything, I haven't committed them yet.
>
> Well... I need to test everything before committing, so my changes
> don't break the code base... at least, that's what I was told earlier
> on in the process ;-)
>
>> As far as asking about methods, what I added made sense and should have made
>> sense to you by them being overridable. I mean;
>
> The aren't overridden in the code that I have access to, as it isn't
> in SVN. Or I wouldn't have been able to remove them and still have the
> code on my side compile and all tests pass.
>
>> Should be pretty clear they were hooks to add sources and SWCs to compile
>> against.
>
> I want to say "clear as mud", but that might be a too little negative
> :-) I didn't see any implementation, so I wasn't able to infer
> functionality.
>
> 'Nuf said, moving on. I apologize if the above sounds defensive of
> unconstructive, I am really only trying to understand.
>
>> 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.
>
> I was already figuring that 'AMD' would be a bit more involved than
> 'goog'. The code Frank suggests for AMD isn't as straight forward a
> translation from AS to JS as 'goog', as it seems to me to require a
> lot more "memory/state" from the compiler. I hope I'm wrong and this
> isn't the case, and you'll be soon ready to give MXML another shot. I
> hope to bring Alex's FlexJS frameworks and approach to FalconJx, so we
> can move forward with only one JS compiler to "worry" about :-)
>
> 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
Re: [FalconJx] TestBase not using 'actual' compile method from MXMLJSC
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Just to clarify some stuff, since this is my "first day back on the
job after a week long sick leave which was supposed to a ski vacation"
(and I'm a bit cranky still as a result... I really shouldn't be in
public) and I need to get back up to speed on our lovely project:
> You don't need to test anything, I haven't committed them yet.
Well... I need to test everything before committing, so my changes
don't break the code base... at least, that's what I was told earlier
on in the process ;-)
> As far as asking about methods, what I added made sense and should have made
> sense to you by them being overridable. I mean;
The aren't overridden in the code that I have access to, as it isn't
in SVN. Or I wouldn't have been able to remove them and still have the
code on my side compile and all tests pass.
> Should be pretty clear they were hooks to add sources and SWCs to compile
> against.
I want to say "clear as mud", but that might be a too little negative
:-) I didn't see any implementation, so I wasn't able to infer
functionality.
'Nuf said, moving on. I apologize if the above sounds defensive of
unconstructive, I am really only trying to understand.
> 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.
I was already figuring that 'AMD' would be a bit more involved than
'goog'. The code Frank suggests for AMD isn't as straight forward a
translation from AS to JS as 'goog', as it seems to me to require a
lot more "memory/state" from the compiler. I hope I'm wrong and this
isn't the case, and you'll be soon ready to give MXML another shot. I
hope to bring Alex's FlexJS frameworks and approach to FalconJx, so we
can move forward with only one JS compiler to "worry" about :-)
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] TestBase not using 'actual' compile method from
MXMLJSC
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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 <er...@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
> <ap...@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 <ap...@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 <er...@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
Re: [FalconJx] TestBase not using 'actual' compile method from MXMLJSC
Posted by Erik de Bruin <er...@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
<ap...@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 <ap...@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 <er...@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
Re: [FalconJx] TestBase not using 'actual' compile method from
MXMLJSC
Posted by Michael Schmalle <ap...@teotigraphix.com>.
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 <ap...@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 <er...@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
Re: [FalconJx] TestBase not using 'actual' compile method from MXMLJSC
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I haven't changed anything, I was asking IF changing it was a bad idea...
I did however remove those two methods, as they were empty and unused.
Maybe we should comment when we add some types of abstract methods
that is only meant to be overridden. I'm not that familiar with Java,
but I think there are ways to achieve that, correct?
I'll be a bit more conservative in the future, but as we're working on
this code now with more than one person, it might be beneficial if we
make our (future) intentions clear?
EdB
On Tue, Feb 12, 2013 at 7:37 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> 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 <er...@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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx] TestBase not using 'actual' compile method from
MXMLJSC
Posted by Michael Schmalle <ap...@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 <er...@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