Hi Harbs,
Great discussion. Just thought for Bead driven tests. - Is this what you
are describing are "Unit" tests actually or UI specific tests - automation
? Cause I cannot distinguish it from discussion above.
Piotr
2017-11-05 10:55 GMT+01:00 Harbs <harbs.li...@gmail.com>:
> On these two points:
>
> > Hmm, that would be cool if we don't need Selenium to report results.
> > Keeping Selenium synced up is a PITA.
>
> For tests that are not browser-dependant, we should not need selenium.
> Testing directly through node should be much faster besides requiring less
> setup.
>
> For tests that rely on browser features, most of the testing frameworks
> I’ve seen use selenium. Most drive it using node.js. Some use PhantomJS,
> and I think there’s an option to run Chromium headlessly. One interesting
> framework which does not seem to use Selenium is cypress.
>
> I’m still looking around. If anyone has experience with JS testing
> frameworks, please let me know...
>
> >
> > I've never looked to see how FlexUnit handles this, but I'm not
> > clear how a test can be written in AS as:
> >
> > @Test
> > Function MyTest() {
> > SetAProperty();
> > AssertSomeOtherProperty();
> > }
>
> I’m not sure how FlexUnit does it either.
>
> Here are two interesting options
> http://nightwatchjs.org/ <http://nightwatchjs.org/>
> https://www.cypress.io/ <https://www.cypress.io/>
>
> The frameworks I’ve seen seem to have a “wait” function.
>
> We could probably also use event listeners.
>
> Here’s a nice list:
> https://www.joecolantonio.com/2016/06/14/top-8-essential-
> javascript-automation-frameworks/ <https://www.joecolantonio.
> com/2016/06/14/top-8-essential-javascript-automation-frameworks/>
>
> 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
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
