Stubbed CI Flow Working

[a-laughlin]

This potentially replaces #32, #21, #48, #20, #46, #33, #34, #35, #36,#29, #51 Also #25, #36 would need upates to remove "build" language, and just keep "test". There may be other tickets this eliminates, but those are all I saw for now.

Story As devs, we should have a stubbed CI flow for each part of the project, so we can easily plug in various tests to the CI once we have them running.

Acceptance Criteria

• test functions stubbed for all parts of proj
• build.py test mobile runs mobile test stubs
• build.py test ml runs ML test stubs
• build.py test api runs ML test stubs
• build.py test runs all tests
• build.py test output should be human-readable when run locally
• build.py test output should be machine-readable when run by CI
• Pushing to our personal branch should result in Travis calling build.py test
• We can open a PR from our branch to master any time, but the PR cannot be merged into master until test_all() passes on Travis
• Explicit override to merge a PR even when tests don't pass should be possible, in case Travis is having issues. I think Github provides an override option by default, so likely nothing to do on this one other than check that the override exists.
• As we understand the project parts better, we should be able to replace stubbed functions with appropriate calls to test the project's different parts (.e.g, expo test for mobile)
• PipEnv to manage dependencies

Depends on:

• travis config permissions (can get from Adam)
• github repo settings config permissions (let adam know what you need)

• 57

Relates to: Slack message:

@everyone Another potential way to simplify. The more we learn about the different project parts, the more I'm realizing that there are some huge differences between a conventional web project and this. For example, a mobile build (i.e., compile) process might produce a packaged app that's publishable to the android/apple stores - something we're unlikely to need (AFAIK). Since we aren't actually publishing distributions, and python doesn't need compiling, I think we can potentially skip compile steps for all parts of the project entirely. Not 100% sure though. Any reasons y'all can think of to have a compile step?

Github flow diagram (though the order is slightly different):

[a-laughlin]

A few things I didn't fully implement on this ticket because they were not possible with my account, or impractical:

• We can open a PR from our branch to master any time, but the PR cannot be merged into master until test_all() passes on Travis (we will see the tests pass on the merge screen, which is more what I actually wanted. Actually preventing a merge is only possible with a pro account)
• Explicit override to merge a PR even when tests don't pass should be possible, in case Travis is having issues. I think Github provides an override option by default, so likely nothing to do on this one other than check that the override exists. (not possible without paying for pro account)
• PipEnv to manage dependencies (I implemented pipenv+pyenv on my machine, so there is a working Pipfile in the directory. However, using unittest by itself there are no dependencies and travis only takes a few seconds. The pipenv implementation was sufficiently difficult that I didn't want to include it in everyone's test process yet, and it will likely slow the build process down significantly. Postponing further work on it until we need it.)

And one I implemented more than the ticket spec'd:

• As we understand the project parts better, we should be able to replace stubbed functions with appropriate calls to test the project's different parts (.e.g, expo test for mobile) (Python testing works in ml and api directories with a few sample tests set up. Plus, I understood the mobile parts well enough to fully implement them. UI snapshot testing active. Pow!)