-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
development workflow is slow - for eg. no test cases #36
Comments
One thing to do is add some infrastructure for running regular unit tests, e.g. with nodeunit. Something like formatting "tracebacks" is a good candidate for unit tests. |
Otherwise having simple testsuite for each supported unit test library, so that I can run them directly within the project, would help. Along with sample log outputs to create better output formatting. |
@rahulnwn @dhimil added some repos and workflow for testing all supported frameworks using ruby script for now https://github.com/browserstack/browserstack-runner/compare/testing |
we can run @nakula's branch with travis to do end to end testing with BrowserStack. |
Between |
does ruby test cases help? On Fri, Oct 17, 2014 at 4:41 PM, Jörn Zaefferer [email protected]
regards |
Yes, it does. |
but we need more unit test cases, keeping this open will keep reminding us that unit tests are pending, thoughts? |
That is a good point, test coverage is still pretty low. Though I don't think keeping this ticket open will help. Instead, when reviewing pull requests, make sure that test coverage is increasing with each change. |
:D On Mon, Oct 20, 2014 at 3:26 PM, Jörn Zaefferer [email protected]
regards |
If you've followed the changes and my comments above, continue here: My changes here break the runner of anything that isn't QUnit. Addressing that requires a lot more work and testing with each supported framework. Since there are no unit tests, testing each changes requires a rather slow run of browserstack-runner. Improving the development workflow should therefore have the highest priority, before anything else is addressed, since that will speed everything else up a lot. I have no idea how to do that, though.
Reference: #35
The text was updated successfully, but these errors were encountered: