I wanted to branch this into a separate discussion because I want to discuss whether this is a good idea or a bad idea on its own.
Harbs > On Nov 5, 2017, at 11:55 AM, Harbs <harbs.li...@gmail.com> wrote: > > I just had an interesting idea for solving the component testing problem in a > Royale-specific way which might be a nice advantage over other frameworks: > > Testing Beads. > > The problem with component test seem to be the following: > 1. Testing at the correct point in the component lifecycle. > 2. Being able to address specific components and their parts. > 3. Being able to fail-early on tests that don’t require complete loading. > 4. Ensuring that all tests complete — which usually means synchronous > execution of tests. > > Testing beads seem like they should be able to solve these problems in an > interesting way. > > Basically, a testing bead would be a bead which has an interface which: > a. Reports test passes. > b. reports test failures. > c. reports ignored test. > d. Reports when all tests are done. > > It would work something like this: > 1. A test runner/test app, would create components and add testing beads to > the components. > 2. It would retain references to the testing beads and listen for results > from the beads. > 3. The test runner would run the app. > 4. Each test bead would take care of running its own tests and report back > when done. > 5. Once all the test beads report success or a bead reports failure, the test > runner would exit with the full report. > > This would have the following advantages: > 1. All tests could run in parallel. This would probably speed up test runs > tremendously. Async operations would not block other tests from being run. > 2. There’s no need for the test runner to worry about life-cycles. The bead > would be responsible to test at the correct point in the lifecycle. > 3. The first test to fail could exit. Failing early could make the test run > much quicker when tests fail. > 4. You could have an option to have the test runner either report all failing > tests or fail early on the first one. > 5. Running tests should be simple with a well-defined interface, and the > actual tests could be as simple or as complicated as necessary. > > This seems like a very good solution from framework development. > > I’m not sure how this concept could be used for application development. I > guess an application developer could create a parallel testing app which is > the same as the app plus testing beads, but that seems awkward. > > Maybe it’s possible to use a testing CSS file which would add testing beads > to components for testing builds, the problem with that is that there’s a > requirement for code to add those beads. > > Maybe we can add special tags for adding the beads via MXML and/or > ActionScript which could be stripped out for non-test builds. > > Food for thought… > Harbs
