* make sure database available as in ```src/main/resources/application.properties```
* make sure database available as in `src/main/resources/application.properties`
* start the application
*```java -jar target/naming-backend-*.jar```
*`java -jar target/naming-backend-*.jar`
Then
* browse to ```http://localhost:8080/swagger-ui.html```
* browse to `http://localhost:8080/swagger-ui.html`
#### Integration tests with Docker containers
See ```src/test/java``` and packages
*```org.openepics.names.docker```
*```org.openepics.names.docker.complex```
See `src/test/java` and packages
*`org.openepics.names.docker`
*`org.openepics.names.docker.complex`
JUnit tests start a docker container for the application (Naming backend) and another docker container for the database (Postgresql) through ```docker-compose-integrationtest.yml```.
JUnit tests start a docker container for the application (Naming backend) and another docker container for the database (Postgresql) through `docker-compose-integrationtest.yml`.
```
@Container
...
...
@@ -67,11 +67,15 @@ Thereafter a number of http requests (GET) and curl commands (POST, PUT, PATCH,
#### Note
* Pre-populated database to be available if data to be available at start of application. Otherwise database may be populated through ```curl``` at command line or Swagger UI.
* See ```src/main/resources``` and sub folders for database scripts.
* If no prior database is available, see integration tests for examples on how to populate database. E.g. tests may be debugged and database content may be examined at any debug point. It's possible to backup database at such debug point and later restore it outside test. In such way, database may be set to state of choice.
* Pre-populated database to be available if data to be available at start of application. Otherwise database may be populated through `curl` at command line or Swagger UI.
* See `src/main/resources` and sub folders for database scripts.
* If no prior database is available, see integration tests for examples on how to populate database. E.g. tests may be debugged and database content may be examined at any debug point. It's possible to backup database at such debug point and later restore it outside test. In such way, database may be set to state of choice.
#### Recommentation
* Have local docker-compose file for database alone if there is need to backup or restore database.
* See `docs` folder to learn about about how ESS Naming Convention is implemented in Naming backend
* what an ESS name is and how to think about it (to better understand how to work with it)
* concept & terminology
* application architecture
* flow of code
* Have local docker-compose file for database alone if there is need to backup or restore database