Home

Welcome

Check in's

Task Workflow

Architecture

Database Schema

CREATE TABLE checkins(
   id varchar PRIMARY KEY,
   teamMemberId varchar,
   pdlId varchar,
   checkInDate date,
   targetQtr varchar,
   targetYear varchar
);

Guilds

drop table if exists guilds;
CREATE TABLE guilds(
   guildid varchar PRIMARY KEY,
   name varchar UNIQUE,
   description varchar
);

Guild Members

drop table if exists guildMembers;
CREATE TABLE guildMembers(
   id varchar PRIMARY KEY,
   guildid varchar REFERENCES guilds(guildid),
   memberid varchar REFERENCES member_profile(uuid),
   lead boolean default false,
   UNIQUE(guildid, memberid)
);

Action Items

drop table if exists action_items;
CREATE TABLE action_items(
   id varchar PRIMARY KEY,
   checkinId varchar REFERENCES checkins(id),
   createdById varchar REFERENCES member_profile(uuid),
   description varchar
);

Checkin Document

drop table if exists checkin_document;
CREATE TABLE checkin_document(
   id varchar PRIMARY KEY,
   checkinsId varchar REFERENCES checkins(id),
   uploadDocId varchar UNIQUE
);

Testing

Service Unit Tests

Junit with Mockito (TBD)

Service End to End

For our end to end service tests we will be utilizing Testcontainers with JUnit 5.

Getting Started

To start writing new end to end service tests you will need to have your test class extend TestContainersSuite.

This abstract class will handle setting up the postgreSQL container which your tests will be using for checkinsdb. This class will zero out the database before each test case, ensuring that your tests will be deterministic and won't affect each other. Lastly it implements the RepositoryFixture, an interface that will contain a way for each of your tests to easily access the database crud repositories without needing to inject them in to your test cases.

Regarding the RepositoryFixture, there are other interfaces that implement the Repository fixture that you may want to implement with your test class which extends TestContainersSuite. These interfaces such as MemberProfileFixture are written to perform common database inserts/queries that one will need throughout their tests. Such as the case for MemberProfileFixture which allows for such things as the quick insert of a new MemberProfile, as many of our service entities require a valid MemberProfile UUID. By calling this one method it will create a default MemberProfile for you and return the entity, which you can then grab the UUID from and use in the creation of your entity. If you think you are going to use a certain query/insert more than once, or that it may have uses for further test cases in the future please add them to a fixture for reuse.

As we are using a real database stood up for these tests, we will not be utilizing Mockito which are used in the unit tests. That means you will have to insert in to the database all the required entities that will make your test case either work or fail as expected. Similar to how we wrote the Mockito when(x).thenReturn(y), using that same thought pattern now we need to have the database match via the appropriate inserts. Again to make this point clear, each @Test will start with a fresh database with only what is available via the Flyway migrations, so you may have to create a new MemberProfile for many of your tests as an example.

Front End Testing:

(TBD)

Automated End to End Testing

Cyrpress (TBD)

REST Endpoints

Sample

• GET /sample/:brand -- See all samples
• GET /sample/:brand/:id -- See a single sample
• GET /sample/:brand/add -- See form to add a sample
• POST /sample/:brand -- Submit data to create a sample
• POST /sample/:brand/:id/save/ -- Submit data to save a sample
• GET /sample/:brand/:id/edit -- See a form to edit a sample
• PUT /sample/:brand/:id -- Submit data from edit form
• DELETE /sample/:brand/:id -- Delete a sample