development workflow is slow - for eg. no test cases

[nakula]

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

[jzaefferer]

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.

[jzaefferer]

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.

[nakula]

@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

[dhimil]

we can run @nakula's branch with travis to do end to end testing with BrowserStack.

[jzaefferer]

Between npm test (added in #97) and ruby tests/test.rb I think this can be closed.

[nakula]

does ruby test cases help?

On Fri, Oct 17, 2014 at 4:41 PM, Jörn Zaefferer [email protected]
wrote:

Between npm test (added in #97
#97) and ruby
tests/test.rb I think this can be closed.

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

regards
Nakul Aggarwal
www.browserstack.com

[jzaefferer]

Yes, it does.

[nakula]

but we need more unit test cases, keeping this open will keep reminding us that unit tests are pending, thoughts?

[jzaefferer]

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.

[nakula]

:D

On Mon, Oct 20, 2014 at 3:26 PM, Jörn Zaefferer [email protected]
wrote:

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.

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

regards
Nakul Aggarwal
www.browserstack.com