The initial db tests found in the /database directory are a sufficient example for using the database driver and controller interactions to save and get data from the databases. However, they are not good tests for what we want to go with in the end. For example, the tests leave behind junk data in the actual databases which we cannot let happen in development and production.
We need to implement a /database test suite which considers the typical flow of an endpoint that requires database interaction(s).
We need to capture this flow of a typical endpoint.
A1- HTTP Request Received. Authorization is checked if necessary.
B1- HTTP Request Processed Into a TPEN Services CRUD or Query Action
C1- Class which supports action determined and initialized (Project, Manifest, Page, Line, Group, User, etc.)
D1- Class logic uses database driver to choose database actions(s) needed for scope of logic
E1- Driver actions interact with database
E2- database gives a response to the Driver action
D2- Class logic receives a response from the Driver action
C2- Class handles logic response and regularizes it
B2- Regularized class response is processed into a RESTful HTTP Response
A2- HTTP Response is sent
Use real database connections sparingly in the tests. Most of the individual line items can use mocks.
The initial db tests found in the /database directory are a sufficient example for using the database driver and controller interactions to save and get data from the databases. However, they are not good tests for what we want to go with in the end. For example, the tests leave behind junk data in the actual databases which we cannot let happen in development and production.
We need to implement a /database test suite which considers the typical flow of an endpoint that requires database interaction(s).
We need to capture this flow of a typical endpoint.
Use real database connections sparingly in the tests. Most of the individual line items can use mocks.