Refactor acceptance test #426
Conversation
|
I know we chatted about this a bit but I don't remember all of the details. What was the goal of these changes again? |
|
Hi @kpdecker, Simple: use QUnit to run the acceptance (JS-only) test. |
|
But what are the advantages to having qunit tests only? Remove the dependency on both ruby and node for the developer tools? One of the advantages of having the split layer here is that the ruby-based acceptance test allow for testing the behavior in a manner that is both representative of the client mode with the full compiler and with only the runtime. This is important for us to test as the node-environment is not the only one out there. Unless we can get this sort of coverage within the node-based tests (might be possible with child contexts, etc) I don't think that it's good to drop the acceptance tests from the ruby tests and frankly I don't want to drop the ruby tests until we can get coverage for all of the test cases that are implemented in the ruby environment, including the tokenizer and parser tests. I'm investigating testling a bit for better client-level testing but I don't think that this is something that is quite ready yet as some of the tests seem to fail due to environmental issues rather than library issues. |
|
Hi @kpdecker, The primary goal is to use QUnit, and not what the Ruby integration spec is providing (QUnit-like). It has been a while, but the suite running in Ruby was not working as expected for new specs (not pushed). There were multiple levels of problems. However, the specs worked as expected when run under npm QUnit or the browser. On the other hand, the tokenizer and parser Ruby tests work well and as expected (they are written in Ruby). Absolutely agree that there is an advantage to running the client mode spec in isolation. That might be better served by independent suites (files) and probably should be done regardless of how the integration tests are run. |
|
@leshill I have noticed a few issues myself. Mostly revolving around trying to apply changes to the 73f2016 resolved most of these issues for me. Does that help with the tests that were failing for yourself? |
|
@leshill I think I'm going to close this rather than letting it sit around. I'm all for trying to unify the testing environment under node (but @wycats might have opinions there :) ), I just don't think that we should do it part way. I.e. I'd like to move all of the tests over including the parser tests, etc and still have the same level of coverage in terms of runtime available vs. not. |
No description provided.