“Units” can mean lots of things to different people. I’m not a purist, and I personally don’t see the value of having tiny unit tests. To me, the importance of tests is to make sure there’s good coverage and there’s insurance that regressive bugs are not introduced.
To me, there’s two types of tests that we need in Royale: 1. FlexUnit-type tests which can be run on multiple environments. The simpler the tests, the better. I see these being good fits for things like utility classes, models, platform-agnostic pieces, etc. 2. “Component tests” or “integration tests” which test that all the pieces work together as expected. Some of the “unit type tests” might be better implemented as “integration tests”. I’d rather have more integration tests than complicated mocks and such to ensure that test cases are completely isolated. For #1, I’m currently working on getting the existing tests working in a JS environment so we can use a single FlexUnit-type test constructs to test on both platforms. For #2, I’m trying to figure out the best strategy. Test beads seem to me like a good way to approach it. > On Nov 5, 2017, at 2:26 PM, Piotr Zarzycki <piotrzarzyck...@gmail.com> wrote: > > 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 > <mailto: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/> >> <http://nightwatchjs.org/ <http://nightwatchjs.org/>> >> https://www.cypress.io/ <https://www.cypress.io/> <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- >> <https://www.joecolantonio.com/2016/06/14/top-8-essential-> >> javascript-automation-frameworks/ <https://www.joecolantonio >> <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> > <https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>>*
