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 <[email protected]>: > 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>*
