Api Controller tests are failing locally

[jconley88]

I've pulled down the repo and installed nodeunit, but cannot get

.../node_apps/co_opencampaigndata/tests$  nodeunit api_controller_test.js

to pass. The output is as follows:

api_controller_test.js
✖ testIndex

AssertionError: 'application/json; charset=utf-8' == 'application/json'
.../node_apps/co_opencampaigndata/tests/api_controller_test.js:34:16

If I comment that test out and run again, I get the following error:

api_controller_test.js

FAILURES: Undone tests (or their setups/teardowns):
- testContributionsJson

To fix this, make sure all tests call test.done()

Any thoughts? Is this failing for anyone else, or just me?

[sampottinger]

Hello!

Well... that's embarrassing. I can reproduce the second (test.done) issue. However, while I certainly believe the first assertion is too fickle / strict and find the behavior you are experience to be very likely, I have not been able to reproduce it yet. There was discussion about this test suite (making this a poorly documented known issue) and I might be in favor of spending our 20% of our 80% test coverage requirement on these front-end controllers. Thoughts?

As a side, thanks for your help and your patience with us on these issues over the last week or so. As a still nascent open source project, I am excited about what we have been able to accomplish and think we have set an excellent and high standard for software engineering discipline. However, I hope we can smooth out practice for more consistent development, particularly in recovering from #32 (which this issue is an artifact of). Also, I hope we can set precedent as new developers come on and old developers leave. I will open a discussion for that separately after http://www.meetup.com/Analyze-Boulder/events/131462802/.

All the best, Sam

[jconley88]

Thanks for verifying that.

I'm not sure what you mean by 'spending our 20%'. Do you mean to remove or relax these tests so that they would have less coverage and thus contribute to the 20% of untested code, or do you mean to increase their coverage. Regardless, I am in favor of having adequate test coverage so that I can confidently modify/extend api_controller. I realize that I'm being vague, but in general I am in favor of more test coverage rather than less. Also, are you using something to measure coverage is it more of a general philosophy?

Hey in response to your aside, no problem and you have been very responsive. Our analyze Boulder team wasn't able to get off the ground, so I was really just interested in finding some other way to contribute while learning a thing or two. I think you guys have done a great job and I'm impressed with the repository. The code is well written and well documented. It's been relatively easy getting up to speed even without much experience with node.

[sampottinger]

Sorry, I should have clarified. I think @trinary and I spent some time thinking about api_controller_tests. They cover a lot of the stack but ended up being a little fickle towards the end of development. I think something could be done to either narrow their scope or, as @trinary pointed out, consider them more as acceptance tests (see discussion on #23).

The code is well written and well documented. It's been relatively easy getting up to speed even without much experience with node.

Thanks! I think that means a lot to us :)

[trinary]

Yes, thanks again for your interest and participation!

API controller tests: Outside of that fixable mime-type check on testIndex (which doesn't show up on master for me :( ), we just need to find a combination of client and server test handlers that set up and tear down properly. I basically ran out of time and while the controller tests worked through most of development, they needed to be run in isolation and killed with ctrl-c because supertest ran a server that didn't get torn down properly.

We should fix these tests and find frameworks to run them that fit with the rest of the test setup. We should mock/double accounts and data interfaces and be able to test the controller in isolation.