> Yeah, I meant functional testing. IMHO, these are functional tests. They > test that the compiler is functioning as a whole. It isn't testing the > individual units like a set of tests for the JSEmitter.java class. And a > separate suite of functional tests for ASJS would probably live in the asjs > repo, not the falcon repo. But I could certainly be wrong here.
That's part of the confusion. Marmotinni is not designed for unit testing the compiler (FalconFX), that's what 'compiler.js.tests' is for. It's designed to test if an application that is designed to do one thing when it's playing in the Flash Player does the same thing when it's playing as an JS application in all of the major browsers. It checks the functionality of an application: functional testing. >> That would be ideal, and maybe we can use the format that mustella >> uses (MXML if I'm correct?) and make marmotinni use the same format, >> making if possible to use the same functional tests for both the AS >> (Flash Player) side and the JS (browser) side. > IMO, MXML or AS. We're in the business of translating either to JS aren't > we? Not what I was saying. Mustella uses MXML as the language to define the tests. I'm saying that we might want to use a similar language to drive a combined AS/JS application functional application test framework. > Yeah, but it seems like I have to override by copying the entire test > including its source instead of having a set of source inputs and an > overridable set of expected outputs. That's what I was thinking of > refactoring. That sounds like a great plan, but it doesn't have any bearing on the current topic ;-) > Well, we own the code for FlexUnit, so at the point it takes the compiler > output and launches the player and tears it down (I am just assuming it does > that) maybe we could change it to use Selenium? In looking a bit at your > commits, it appears I need a .java file for each test or set of tests. That > may not be helpful for the AS-side so just being able to declare in MXML or > AS what the expected output is and then have an engine or engines that > compile and run in different configs and test against those outputs seems > like it would enable more folks to write tests. I think it might be > possible to tweak your TextButton.java to pick up its expected output from > some external file and thus become part of that engine. If FlexUnit can test the functioning of an application (i.e. check the value of a label after it has faked a click on a button, triggering an event handler), then I'm all for it. Maybe Mike can chime in on this? Point of order: why do you seem so opposed to this contribution? I've put a lot of effort in it, and it serves a function that I don't see any of the other tools being able to without serious modification... It's not like this project is drowning in active contributors, so why look a gift horse in the mouth? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
