Your main job for this week is to integrate the role code that you developed in P103 with the code that your partner wrote for P103, and with your iterable tree implementation from P106.
Replace <YourNetID> with your NetID to clone a repository with your integration partner’s and your role code implementation: git clone https://$(cat ~/.gitlab.access)@git.doit.wisc.edu/cdis/cs/courses/cs400/202501/students/<YourNetID>/P107.Integration
Navigate into your P107.Integration folder, and then run the provided script ./getBranches once to create local copies of the branches from the P103 repos of both yourself and your partner, as well as your P106 tree implementation. After cloning the repository and running this command, verify that you are currently on the main branch by running: git branch -vv. In addition to the active local branch main, you should now also see three additional branches: - one named backend and one named frontend: these should contain the P103 role code contributions from you and your partner, - one named tree which contains your IterableRedBlackTree from P106.
Note that these three extra local branches are each connected to different remote repositories on gitlab, and that running git pull and git push while any of these branches are checked out will lead to pushing and pulling changes to and from those older repositories (although you won’t have permission to push to your partner’s P103 repository). This should help you share bug fix changes made to your P103 repository with each of your groupmates that are integrating with your role code.
The only one of these branches connected to your P107.Integration repository on gitlab is the main branch. And in gitlab, you should only ever see this one branch (to avoid confusion with the others that you are locally working between).
You will be working with the P103 role code of your assigned partner this week. If you are unsure about which teammate you chose or were assigned to work with, you can run git remote -v inside your P107.Integration folder, after running the script command above. You’ll see your NetID and your partner’s listed next to the frontend-remote and backend-remote lines in this output. In addition to using your piazza group to communicate with your teammates, you can also attempt to communicate directly with your partner for this assignment by appending “@wisc.edu” after their NetID.
Although everyone has been paired with a groupmate for this final week of project 1, each individual student is responsible for integrating, and developing tests along with an application for this first course project. If you find any bugs in your partner’s code, please follow the instructions below to share such concerns with both your partner and the course staff.
We have pushed the reviews of your code that your teammates wrote into your feedback repo at (replace <YourNetID> with your NetID): https://git.doit.wisc.edu/cdis/cs/courses/cs400/202501/feedback/<YOUR_NETID> Please review this feedback carefully.
After reviewing this feedback, create lists of the improvements to your code that your teammates recommended, which you would like to include in your final project 1 submission. Submit your list to this form. You will be tracking the specific commit IDs that include each of these changes in your final submission.
Once you have submitted your list to the form, checkout the branch for your own role within your local P107.Integration repository folder. Then, work through refining your code and implementing your teammates’ recommendations for improving your code. Commit and push often during this process, so that the revisions you make are all well documented in your commit messages. For each recommendation from your teamates that you implement, list the specific commit ID of the commit that contains the improvement in the form linked above. If you decide not to implement one of the recommendations, list your reason for this in the submission form.
Once you have revised your code, make sure to push all your commits with your revisions to the remote. For this, make sure you are on the branch with your P103 submission that you committed your improvement to, then run the command git push. After you have pushed your improvements, let your teammates know by posting in your team’s piazza group that you have pushed an updated version of your code into your repository.
Watch out for messages from your integration partner on piazza, then checkout their branch and run git pull to copy your partner’s commits with their improvements into your own repository.
Submit your completed form and push your improvements to the remote repo by the midweek deadline: Saturday October 18
Switch to the main branch of your local repo. Merge the contents of your tree branch into this main branch, so that you can utilize your IterableRedBlackTree for this project. Then, merge the branch with your improved role code contributions into main. Next, make sure your have your partner’s latest work in your local repository by running git pull on their branch inside your local repository. Then, merge your partner’s improved P103 contribution into your local main branch. During this merge, you may need to resolve conflicts manually, which is likely if you or your partner made edits to the Tree_Placeholder classes in the submissions. In this case, we recommend using the backend developers version of the class.
For all of the work beyond this point in the write-up, you should be working on your own main branch. Only role code bug fixes should be made to, and pushed from, the branch of your role specific P103 code. After you or your partner do this, you’ll want to re-merge changes from those role specific branches into main.
Update App.java to replace the instantiation of the Tree_Placeholder with an instantiation of your IterableRedBlackTree, and the instantion of Backend_Placeholder with the full Backend implementation written by either yourself or your partner, depending on your role. After your updates, there should be no reference to any placeholders in your App.java.
Next, create, add, and commit a Makefile that has the following targets:
runApplication: compiles all necessary classes, then runs the app.runAllTests: compiles all necessary classes, then runs your test class with the JUnit 5 test runner. This target should reference the junit5.jar file in the parent folder of P107.Integration. Note that while running other tests, such as your partner’s test classes or tests in P106, might be helpful for your own testing purposes, the runAllTests target only needs to run the tests defined in your own BackendTests.java or FrontendTests.java. See step 5 Develop Integration Tests below.clean: deletes all class files in the P107.Integration folder.Make sure that all targets work as expected before committing and pushing the final version of your Makefile.
While you’re working through updating your App.java, you might encounter additional bugs in the merged code. When you do, trace through your code to find the reason for those bugs that you encounter during this process in your own code. If you suspect that those bugs are 1) either caused by a bug in your partner’s code, or 2) by different expectations about methods of the interfaces you or your partner implemented, communicate with your partner about what you found.
During this process, you are not responsible for fixing any bugs in your partner’s code, but you are responsible for communicating with them and giving them all the information you have to help them reproduce and resolve bugs in their code. Sharing code for a test that reproduces a bug is a great way of doing that.
If you or your partner make any changes to your own role code during this process, the person whose code is being changed can make those changes in their local branch with their P103 contribution and then git commit into that branch and git push from there. After the push, the other partner can run git pull to transfer the new commit(s) into their own repository’s branch from that role. From there, you and your partner can both merge such improvements in each of your individual main branches.
After merging both P103 contributions into your main branch, open up your test class from P103 (labelled with your role for this project). Within this class, add, commit, and push the code for four additional test methods. The four test methods should:
In your test code, you can use the TextUITester to simulate input and capture output from the frontend, but you are not required to use it and can rely on the methods exposed by your app’s frontend interface instead.
If you encounter any bugs while you are developing and running your tests, use the process in step 4 above to resolve any bugs in your or your partner’s code. And make sure that your old tests from P103 continue to run and pass. Those old tests should not be updated this week, and should continue to run and pass using placeholder classes. If you need to make minor changes to keep them running and passing, you are welcome to do so while you complete this week’s work.
Record a short video demonstration that shows the capabilities of the app. You are welcome to use any video capture software that you are comfortable using for this assignment. If you don’t have any preference or prior experience with such software, we recommend using Kaltura Capture to make this recording. For users of other software, choose to add a new “Media Upload” rather than “Kaltura Capture” in the instructions above, and then follow those later instructions to make the video unlisted, before retrieving and testing a shareable link.
The requirements for the demo video are:
After creating your video, please review your video carefully to make sure that it includes the requires content, that any demonstrations are clearly visible, and that your voice is audible in it. Then, submit your video link to this form.
Make sure you have complete your submissions to both the midweek form and the video link form.
Make sure that you have pushed your latest commits on the main branch and on your P103 role code branch.
Check whether your submission successfully transferred to gitlab (noting that ony your main branch should appear in your P107 repo on gitlab) and also whether it passed our pre-grading correctness scans by running the cs400 script with the check argument as follows: cs400 check. You may need to wait a minute or two before the scan finishes to get the feedback you are interested in from his command. Another way that you can check the contents of your most recent submission is to log into DoIT’s gitlab instance (using the UW-Madison NetID button at the bottom of the page), and navigate through the contents of your submission within your P107.Integration project there.
| Criteria | Points |
|---|---|
| Code Revision and Response to Reviews by Midweek (Sat, Oct 18) | 1 |
| Code Revision and Response to Reviews | 4.5 |
| Merging and App.java | 3.5 |
| Working Makefile | 3 |
| Integration Tests | 4 |
| Video | 4 |
| — | |
| Total Points Possible | 20 |