Comments inline. > Each Mixin brings in one class, but that class can drag in tons of stuff. > The key question for our users is how they want to determine what gets > tested. From prior Adobe Flex users, they didn't want to add testing > overhead to every MXML component, only certain ones, and often needed to > assign it a different name than the id in order to have meaningful output. > Especially because an id can be used in more than one place in MXML. > Individual automation beads can be placed on each instance that you want > tested, but that changes the source code. Having an external map that the > Mixin uses to walk the DOM and add beads doesn't affect the source code.
This is clearly beyond my level of expertise. It would probably be helpful to get input from users who have had clear testing strategies in the past. This is a topic that I’ll probably be able to better grok once we have framework unit and integration testing more solid. > To me the "Later" problem is about how to sequential lines of > ActionScript/JavaScript don't get run sequentially in order for the > runtime to do some processing. I don't understand how a bead can do that > if the tests are written in a non-declarative language. Events. I’m making the assumption that all integration tests would be written inside a test bead. For example, layout testing could set some properties and then listen for layoutComplete to check that the layout was done correctly. I’d probably make TestBeadBase have some kind of test() method to properly route the test and results to the main test runner. >> >> I’m not sure what you mean by this. What timeouts are you concerned by? > > Flash for sure won't let you run code for more than 60 seconds without > letting the player do its thing. I thought there were timeouts for > JavaScript in browsers, and potentially for operating systems thinking a > process is "not responding". The runtime probably needs to be given a > chance to do something between tests. If the test runner is running in node, node is async, so this is not a problem. If it’s running in a browser it can also be async using events and callbacks. I’m not sure where there would be a tight loop that would cause problems. > One theory of testing says that you should test boundary conditions of > every code path as well as some intermediate values. Royale should have > fewer "if" statements and other code path forks in the beads because we > are trying to write PAYG code and every "if" theoretically introduces > "just-in-case" code. > > So, in theory, if you could describe the boundary conditions in metadata, > you could write a test case generator. I do not enjoy writing and > debugging test cases so having something generate the tests would make > life much easier for me. The theory sounds good to me… ;-) Harbs
