Closed darscan closed 7 years ago
I started porting these tests to AS3:
https://github.com/promises-aplus/promises-tests
What a.. nightmare.
I'm pretty sure you've tried this, but what about running those tests through an adapter and ExternalInterface.
Unfortunately, without tests this library (or any other) can't be considered reliable.
Thus far it's leaned on being as direct as possible a port of the CoffeeScript implementation (which does pass the Promise/A+ test suite). But that's hardly enough.
Implementing an ExternalInterface adapter would be quite a feat, since function references don't survive across the bridge. I went as far down that rabbit hole as I dared with SWFService, but that required lots of manual correlation based on runtime generated ids on both sides of the bridge.
Ultimately, we'd have to port the compliance tests to AS3. The time required to do that is a hard sell when buried with paying Objective C and JavaScript work.
Ultimately, we'd have to port the compliance tests to AS3. The time required to do that is a hard sell when buried with paying Objective C and JavaScript work.
Yeh, I hear ya. I took me hours to port section 3.2.2 (which is roughly 1/10th of the test suite).
@darscan if you made a start on porting compliance tests, could you post it on github?
I would really like to get started together on this one, so @darscan can you please somehow share what you already did?
And even if sharing the progress is not possible right now I have some questions:
Looking forward to invest some time to this.
Hey Karfau,
My preference would be FlexUnit, since it is both an ActionScript 3.0 and Flex testing framework (despite the name), is still actively maintained (as part of the ongoing Apache efforts), and has integrated support in both Adobe and Jetbrain's IDEs.
I will be integrating Thomas's pull request soon. He and I have worked together for years, and his pull request is major step in the direction that he and I have discussed toward making this a more flexible library (capable of generating as3-only and Flex builds). I foresee one more structural change to the project, to introduce another set of top level folders to accommodate a unit test project within the same repository.
An ideal model of a library that structures its project(s) in this way would be hamcrest-as3:
I would definitely welcome any contributions you made toward porting the Promises/A+ test suite. Let me know if there's anything I can do to assist!
Hi. It seems 3.X was moved to 2.X with this commit:
https://github.com/promises-aplus/promises-tests/commit/911715ab7bd1b40b348e2915177e0dbaa88ad5f7
I used FlexUnit 4, but alas, I cannot find the source anywhere (I've changed machines and lost some backups). Honestly though, it was just a couple of hours of hacking - the most annoying bit was setting up some async helpers to get FlexUnit to play nice.
My preference would be FlexUnit
Agreed. As much as FlexUnit annoys me (with its mad deep stack heap and such), it's a standard, and I do enjoy the direct integration with IntelliJ.
Thx for the fast response.
I don't have a problem with FlexUnit as with the new structure this will only introduce Flex as a test-dependency. (not sure how this can be configured properly in IntelliJ...)
As I'm currently working on a small project that uses the lib i will give the 2.1 section a try to get familiar with it.
When the structure changes I will gladly provide what I already have done. (do you have any "timeline goal" for this to happen?)
Just a thought...
Given the shared heritage of ActionScript and JavaScript, I wonder if it would be possible to write adapter functions for the utility methods that the Promises/A+ compliance test suite expects to find (describe()
, it()
, assert
, etc.), leveraging the FlexUnit equivalents. Ideally, we would set up an environment in which we could run the majority of the test suite code verbatim.
Otherwise, keeping in sync with future releases of the compliance test suite could become quite the burden in the future.
That said, I haven't done any work to see how viable this approach would be.
For promise-as3 specific tests (i.e. tests for language and library-specific features and utility methods, adapters, etc.), I would expect we would still structure and implement like a typical FlexUnit test.
With my current approach i think keeping things in sync should not be to diffucult, as I can copy most of the code when porting the test suite.
I already reached 21 tests finishing section
2.2.2.2: it must not be called before promise is fulfilled.
I oriented the structure and execution patterns to the existing ones. I didn't have a look at all tests, maybe there will be some problems to solve but until now nothing unsolvable occurred. For a detailed discussion/the questions I had while porting see promises-aplus/promises-tests#52
I even did it in a way that only the Promise class is specified in all test classes and there are some untyped "adapter" methods in the root package of all the test (i did choose com.codecatalyst.promise.spec
) that are used as in the JS version.
This should allow for easy adoption for other implementations.
I'm looking forward to fork and send a pull request as soon as the pull request is in and/or the new structure is ready.
@karfau Nice :+1:
after having this progress and thinking about how long i will have to wait until I can commit, I decided i will open an own repo so I can commit/push each step and everybody can have a look or even contribute.
I put some more work in the basic structure and as far as I understood it so far, beside one feature of the test framework those tests are ported from, it works somewhat identical.
the tests should be easy to compare to the JS-sources, and there is even an adapter so that the tests are completely free of class references to this (kind of reference) implementation.
And I finally did pushed my current state, so everybody interested can have a look: karfau/promises-tests-as3
If I prepare a PR with FlexUnit tests, will it be merged? Is this project still alive?
We need them