royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Test Beads (was Re: Unit Tests et. al.)
Date Sun, 05 Nov 2017 10:14:53 GMT
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.lists@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message