This issue should be completed after the issue with the title "Create database table for RecommendationRequest"
Overview
In this issue, you'll create a Controller. In the Spring web framework, a Controller is a file that maps request URLs (e.g. /api/RecommendationRequest/all to some code that runs to produces the response to that request.
(1) First locate the directory where the Java source code files for controllers can be found:
UCSBDatesController.java (if your database table a numeric @Id field)
UCSBDiningCommonsController.java (if your database table uses a string field as it's @Id field)
Keep this file open in one window; you'll need this as source material for the file you are about to create.
(3) In a separate window, create a new file called RecommendationRequestController.java in the src/main/java/edu/ucsb/cs156/example/controllers directory.
From the example file, copy over:
all of the imports
the top level class annotations (e.g. @Tag, @RequestMapping, @RestController and @Slf4j) adjusting them as needed
the @Autowired declaration of the repository class for your database table; this gives you access to the database table. The @Autowired declaration signals
the Spring boot framework to automatically invoke the constructor for this class so that you don't have to. Using @Autowired
also allows the code to automatically switch between using a real database when running as a web app,
or a "mock" database when we do unit testing of the controller methods.
(4) Don't copy over all of the methods yet; just copy over these two methods with these annotations:
Annotation
Purpose
@GetMapping("/all")
Get all records in the table and return as a JSON array
@PostMapping("/post")
Use the data in the input parameters to create a new row in the table and return the data as JSON
(5) Edit the names of the fields, etc. to match your database table.
(6) Next, use Swagger to see if your methods work. Debug until you get correct results using Swagger.
(7) When your interactive testing works, we'll move on to creating automated tests. Locate the directory for controller tests:
Find the file with tests for the controller you used as a basis for your controller file,
i.e.
UCSBDatesControllerTests.java (if your database table a numeric @Id field)
UCSBDiningCommonsControllerTests.java (if your database table uses a string field as it's @Id field)
Keep this file open in one window; you'll need this as source material for the file you are about to create.
(8) In a separate window, create a new file called RecommendationRequestControllerTests.java in the src/test/java/edu/ucsb/cs156/example/controllers directory.
(9) From the source file you identified in step (7) above, copy over:
all of the imports
the @WebMvcTest(...) annotation (be sure to change the parameter here to the name of the controller test you are testing; forgetting to do so is a common source of errors)
the @Import(TestConfig.class) annotation (this one stays exactly as it is)
the @MockBean declaration for the repository for your new database table; this creates a "mock" (i.e. "fake") database object using a Java package called Mockito)
the @MockBean declaration for the UserRepository; this is needed so that we can work with the mock users to test what happens in various scenarios: user not logged in, regular user logged in, admin user logged in
Be sure to change the name of the controller class to match the one for your database table.
(10) Next, copy over just the tests that pertain to the methods you defined in your controller so far, i.e. the ones under the comments:
// Tests for GET /api/ucsbdiningcommons/all
// Tests for POST /api/ucsbdiningcommons...
You'll see additional tests for another GET method, as well as DELETE and PUT; we don't want
those tests yet (that's a later issue).
(11) Check test coverage with mvn test jacoco:report; to read the report, open target/site/jacoco/index.html in a web browser. Iterate until you have 100% line/branch coverage.
(12) Check test coverage with mvn test pitest:mutationCoverage; to read the report, open target/pit-reports/index.html in a web browser. Iterate until there are no surviving mutations (e.g. >> Generated 61 mutations Killed 61 (100%)). You may ignore line coverage of less than 100% reported by pitest (e.g. this is fine: >> Line Coverage: 171/175 (98%)).
Acceptance Criteria:
[x] There is a controller file RecommendationRequestController.java
in the expected directory.
[x] In RecommendationRequestController.java there is
code for a GET /api/RecommendationRequest/all endpoint
that returns a JSON list of all RecommendationRequests in the database.
(We sometimes call this an index action since it lists all
items in the database.)
[x] In RecommendationRequestController.java there is
code for a POST /api/RecommendationRequest/post endpoint
that can be used to create a new entry in the table. (This
is a create action.)
[x] The Swagger-UI endpoints for these are well documented so that
any member of the team can understand what they are for and
how to use them.
[x] The POST endpoint works as expected, in the sense that new
records can be added to the database (on localhost).
[x] The GET endpoint works as expected, in the sense that the new
records that are added show up (on localhost).
[x] The GET and POST endpoints work as expected when the
app is deployed to Dokku.
[x] There is full test coverage (Jacoco) for the methods in
RecommendationRequestController.java
[x] There is full mutation test coverage (Pitest) for the methods in
RecommendationRequestController.java
In the description, include the text "Closes #n" where n is the number of
this issue.
Then ask for a team member to review your PR.
Finally: drag this issue from "In Progress" to "In Review".
Review Others' PRs: Next, see if there are any PRs that need to be code reviewed and merged. Unless you are the
first person on your team to complete a PR, there likely is at least one.
See:
Dependencies
This issue should be completed after the issue with the title "Create database table for RecommendationRequest"
Overview
In this issue, you'll create a Controller. In the Spring web framework, a Controller is a file that maps request URLs (e.g.
/api/RecommendationRequest/allto some code that runs to produces the response to that request.(1) First locate the directory where the Java source code files for controllers can be found:
src/main/java/edu/ucsb/cs156/example/controllers(2) Then, determine which example file you are going to use as a basis for your controller by reading the team02 instructions about the
@Idfield here: https://ucsb-cs156.github.io/w24/lab/team02.html#two-types-of-id-values-for-an-entity-classThe two candidates are:
UCSBDatesController.java(if your database table a numeric@Idfield)UCSBDiningCommonsController.java(if your database table uses a string field as it's@Idfield)Keep this file open in one window; you'll need this as source material for the file you are about to create.
(3) In a separate window, create a new file called
RecommendationRequestController.javain thesrc/main/java/edu/ucsb/cs156/example/controllersdirectory.From the example file, copy over:
@Tag,@RequestMapping,@RestControllerand@Slf4j) adjusting them as needed@Autowireddeclaration of the repository class for your database table; this gives you access to the database table. The@Autowireddeclaration signals the Spring boot framework to automatically invoke the constructor for this class so that you don't have to. Using@Autowiredalso allows the code to automatically switch between using a real database when running as a web app, or a "mock" database when we do unit testing of the controller methods.(4) Don't copy over all of the methods yet; just copy over these two methods with these annotations:
@GetMapping("/all")@PostMapping("/post")(5) Edit the names of the fields, etc. to match your database table.
(6) Next, use Swagger to see if your methods work. Debug until you get correct results using Swagger.
(7) When your interactive testing works, we'll move on to creating automated tests. Locate the directory for controller tests:
src/test/java/edu/ucsb/cs156/example/controllersFind the file with tests for the controller you used as a basis for your controller file, i.e.
UCSBDatesControllerTests.java(if your database table a numeric@Idfield)UCSBDiningCommonsControllerTests.java(if your database table uses a string field as it's@Idfield)Keep this file open in one window; you'll need this as source material for the file you are about to create.
(8) In a separate window, create a new file called
RecommendationRequestControllerTests.javain thesrc/test/java/edu/ucsb/cs156/example/controllersdirectory.(9) From the source file you identified in step (7) above, copy over:
@WebMvcTest(...)annotation (be sure to change the parameter here to the name of the controller test you are testing; forgetting to do so is a common source of errors)@Import(TestConfig.class)annotation (this one stays exactly as it is)@MockBeandeclaration for the repository for your new database table; this creates a "mock" (i.e. "fake") database object using a Java package calledMockito)@MockBeandeclaration for theUserRepository; this is needed so that we can work with the mock users to test what happens in various scenarios: user not logged in, regular user logged in, admin user logged inBe sure to change the name of the controller class to match the one for your database table.
(10) Next, copy over just the tests that pertain to the methods you defined in your controller so far, i.e. the ones under the comments:
// Tests for GET /api/ucsbdiningcommons/all// Tests for POST /api/ucsbdiningcommons...You'll see additional tests for another
GETmethod, as well asDELETEandPUT; we don't want those tests yet (that's a later issue).(11) Check test coverage with
mvn test jacoco:report; to read the report, opentarget/site/jacoco/index.htmlin a web browser. Iterate until you have 100% line/branch coverage.(12) Check test coverage with
mvn test pitest:mutationCoverage; to read the report, opentarget/pit-reports/index.htmlin a web browser. Iterate until there are no surviving mutations (e.g.>> Generated 61 mutations Killed 61 (100%)). You may ignore line coverage of less than 100% reported by pitest (e.g. this is fine:>> Line Coverage: 171/175 (98%)).Acceptance Criteria:
RecommendationRequestController.javain the expected directory.RecommendationRequestController.javathere is code for aGET /api/RecommendationRequest/allendpoint that returns a JSON list of allRecommendationRequests in the database. (We sometimes call this an index action since it lists all items in the database.)RecommendationRequestController.javathere is code for aPOST /api/RecommendationRequest/postendpoint that can be used to create a new entry in the table. (This is a create action.)POSTendpoint works as expected, in the sense that new records can be added to the database (on localhost).GETendpoint works as expected, in the sense that the new records that are added show up (on localhost).GETandPOSTendpoints work as expected when the app is deployed to Dokku.RecommendationRequestController.javaRecommendationRequestController.javaNext issue
What to do next
When you've met all of the acceptance criteria:
Make a PR: Do a PR for this branch, being sure to enter a reasonable title and description.
In the description, include the text "Closes #n" where
nis the number of this issue.Then ask for a team member to review your PR.
Finally: drag this issue from "In Progress" to "In Review".
Review Others' PRs: Next, see if there are any PRs that need to be code reviewed and merged. Unless you are the first person on your team to complete a PR, there likely is at least one. See:
Start your next issue :
Now you can complete these in any order:
GET(show) endpoint for a single record in RecommendationRequest tablePUT(edit) endpoint for a single record in RecommendationRequest tableDELETEendpoint for a specific record in RecommendationRequest table.Find the issue you are going to work on next on the Kanban board.