OOSE

For this iteration you should have some sort of skeleton app fully standing up. Most of the features may be missing, but the project should be fully integrated and running.

• Getting good tests is a major focus of this iteration.
  • We are going to explicitly look for good coverage with tests in this iteration and going forward. You are strongly encouraged to use a code coverage tool.
    • In Java, IntelliJ comes packaged with one or use the EcLemma plugin in Eclipse
    • in Python, nosetests --with-coverage will do it once you install the nose test framework and the coverage module
  • Back-end tests are required; front-end tests are optional unless your front-end has serious domain logic in it.
  • We also will be looking for TravisCI integration testing in this iteration, you will lose points if you don't have it and your CA did't approve you skipping it (because Travis cannot test your app).
  • Testing will be at least 25% of your iteration grade as added encouragement to put some time on that aspect now.
• Build and deploy is also an important focus.
  • You are required to have a clean build and deploy process - work with your advisor to make sure they can easily build and test your project. There is no hard requirement on how you need to do that, but you may want to make a dockerized deployment, or deploy to Heroku or AWS, etc.
  • Make sure to give instructions in the README whereby your advisor can clone, build and locally run your server (and your frontend if it is Android/iOS, etc) without turning their brain on, in other words they should just be able to copy/paste command lines from your top-level README. Also include similar instructions for running your test suite.
  • If you are deploying your server to Heroku/AWS/etc make sure you have a deployment methodology (script etc) that is documented in your README.
  • We will assign around 10% of the iteration grade to this, in particular whether we can get your server running and to run your tests.
• Lastly, we are giving you a heads-up that we will be looking in detail at how Git is being used by your team (hopefully you are already doing all of this):
  • You need to do your own development on a branch, and you need to integrate that into master on a regular basis - we don't want to see your project without an integrated master branch at the iteration submission point.
  • Don't make personal branches for each group member, that is an abuse of git branches -- they are for feature additions or other tasks, which should not be perfectly tied to people.
  • You need to get a clear workflow going for how code is integrated on to your master branch. We recommend you experiment with using git pull requests when you are proposing to integrate some code from your branch into master. This topic was covered toward the end of the lecture git tutorial, please look there for more details of why and how.
• The format for Iteration 4 submission otherwise follows Iteration 3; make sure to keep using GitHub issues, update your project boards to reflect your revised plan for future iterations, update your README.md, and update CHANGELOG.md to reflect what you accomplished in this iteration.