a) All the database stuff should be in db/ and db/migrations/
b) All the API stuff should be in api/
c) The unit test directory structure should match - so tests/db/, tests/api/, etc.
2.
.env files would be replaced by the oslo_config stuff that @ljmcgann and @DanNiESh are working on.
3.
changing file structure, i.e. moving models to objects and resources to api, test files, etc.
4.
shouldn't have the if name == '__main___' block in there anywhere. Should be setting up a console_scripts entrypoint so that the service can be run from the command line.
5.
more tests
note:
For the system tests, I wanted to use a separate db for testing, and we don't have one right now in the environment, so I used elephant sql's postgres as a service for this. So every time the tests run, the tables are initialized from scratch and then teared down. Since I used postgres, the dateTime field in the db is changed bit so in the system tests I mostly used status code validation. However, once we have another solution that is not using postgres, I will add output validation to the system tests as well.
The postgres as service is only a short term solution to make sure the tests run correctly. The setup for the postgres is in the tests/base_test.py file.
Still needed:
1.
a) All the database stuff should be in db/ and db/migrations/ b) All the API stuff should be in api/ c) The unit test directory structure should match - so tests/db/, tests/api/, etc.
2.
.env files would be replaced by the oslo_config stuff that @ljmcgann and @DanNiESh are working on.
3.
changing file structure, i.e. moving models to objects and resources to api, test files, etc.
4.
shouldn't have the if name == '__main___' block in there anywhere. Should be setting up a console_scripts entrypoint so that the service can be run from the command line.
5.
more tests
note:
For the system tests, I wanted to use a separate db for testing, and we don't have one right now in the environment, so I used elephant sql's postgres as a service for this. So every time the tests run, the tables are initialized from scratch and then teared down. Since I used postgres, the dateTime field in the db is changed bit so in the system tests I mostly used status code validation. However, once we have another solution that is not using postgres, I will add output validation to the system tests as well. The postgres as service is only a short term solution to make sure the tests run correctly. The setup for the postgres is in the tests/base_test.py file.