Create tests and fixtures

[danielcash]

Here's an easy one. Let's get some basic tests set up and running. We can integrate with travis-ci to keep an eye on things, and to make sure our pull requests are good to merge.

We should also keep some fixtures to help expedite writing thorough tests. These can be as simple as something like example_person.json. We can load this json in the tests to create/update models and verify that our models are serialized correctly.

[williamflaherty]

I like the idea of tests but after investigating Travis-CI I don't want to put the money toward it right now. (Hopefully this comment is funny in the future.) But, I do like the idea of tests so I'll investigate the cost to setup AWS server with jenkins (which has a github plugin).

Something something second paragraph I know those words but not in that order. I assume you mean we should have static files that our tests run on so we know we're not fucking up the app when we make changes to the API?

[danielcash]

Right. Just some .json files that have example users, messages, etc.

[danielcash]

Fair point about Travis-CI, I didn't really think about the fact that people have to exchange money for things. I don't think it's absolutely crucial that we have continuous integration at this point, as long as we do our due diligence in running the Django tests before merging.

[Mimimiel]

I could have sworn I commented on this issue yesterday, but I've got test cases for register_person and update_person that I'll make a PR for sometime today. Technically, #20 needs to merged in first before the test cases will pass.

[Mimimiel]

Okay so after discussing for an hour with Dan and putting even more time into it, view tests are horrid and confusing. We want to test status codes accurately (re: write a test case that reveals the 403 register_person in #20 is currently returning), but it's like :negative_squared_cross_mark: (because being green and an X is a very confusing life state).

While controller test cases are clearly directed to testing effectiveness/functionality, Dan and I are discussing what the view tests should be testing exactly. Current thoughts:

• status codes
• serializers (in the test itself)
• response/request formats

[Mimimiel]

Managed to test the status_code only by having the view and controller named differently. Will investigate more later.

[Mimimiel]

Tests for login and authenticate methods still need to be written. Tag @danielcash, you're it, no tagbacks. Totes pawning this off on you because after struggling with the login view continuously telling me there was no .DATA in the request object, I thought, "Hey, who knows how to test views better than I do? Dan. Dan knows."

[Mimimiel]

Figured out that the reason testing the login wasn't working using the standard pattern of the other view tests is because the login doesn't have DRF's @api_view decorator

[danielcash]

Good work, @Mimimiel. I'm closing this since we've actually implemented some tests and will hopefully continue to do so in the future.