Functional Tests
cpsubrian opened this issue · comments
I'm working on functional tests for my memcached request handler. This is uncovering some broken methods in the core api.
I'd like to add functional tests here (that hit an actual elasticsearch server). They'll end up looking something like this: https://github.com/cpsubrian/elasticsearch-memcached/blob/master/test/core.js
I don't want to step on the current tests at all. Do you guys have any preference on how I add these? Technically I should be able to get them working in travis. Not sure how coveralls works though.
This sounds great to me! For the coveralls.io stuff, the quickest way to see impact would be to run the following commands:
npm run-script coverage
open reports/coverage.htmlThat will show you what coveralls.io will ultimately report in terms of test coverage. What I've noticed is that when running integration tests, the additional libraries being used tend to get pulled in for test evaluation as well and often that significantly reduces the coverage number. If this is the case after you introduce functional tests, we can modify the posttest script in package.json to only run coverage when performing units and then do the functional integrations after.
From an organizational point of view .. would you want all the tests as one commit (they will be failing), and then fix each test one by one? Or would you prefer adding each test&fix as separate commits?
I don't have a preference. Whatever you'd prefer.
- Nick Campbell
On Fri, Aug 16, 2013 at 2:27 PM, Brian Link notifications@github.comwrote:
From an organizational point of view .. would you want all the tests as
one commit (they will be failing), and then fix each test one by one? Or
would you prefer adding each test&fix as separate commits?—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-22784601
.
Going to close this now in light of @cpsubrian's recent functional tests merge.