5#Flipwise Submission
- Clone the Project Flipwise repository and open the folder in your Intellij (preferred to easily make JavaDoc)
- Go to file Main.java located in the src/main/java directory
- Right click on the Main and select Run Main.main()
- Run test configuration by selecting 'Testing Configurations' in the Configuration dropdown
- Select 'Run Testing Configurations with Coverage' button three buttons left of Configuration dropdown
- Unfortunately, for testing purposes, we need a test database. Since we have not generated enough data to run our tests on , our tests do not compile as of now. We will complete our tests and submit for Milestone 5.
- Coverage Report will thus indicate that all significant files, are tested to 0%.
- On the top of Intellij, open the Tools dropdown and select GenerateJavadoc
- Select 'Whole Project' for Javadoc Scope and push the generate button
- [] Example: (where the code is mention it)
- [] Our project has a lot of potential for further feature extensions beyond our time in this course. Further down, we may have many different instances of Debt in our program
- [] As a result we do not want a hard dependency on the Debt class within the PurchaseBalances Class.
- [] Thus, when we want to add a Debt pair, we create the Debt pair outside the class, and inject it inside.
- [] This way, we can accomodate for future subclasses of Debt
- [] Example:
- [] All our presenter classes follow clean architecture and as a result implement their respective outputboundary interfaces.
- [] The corresponding use case modifies the data and once done utilizes the output boundary which notifies the presenter of the changes that have been made through the output data structures.
- [] In this way, an object is able to notify other objects without making assumptions about who these objects are.
- [] We plan on implementing an iteration design for our classes were we have stored data in List or other Collection objects (such as PurchaseBalance, PurchaseList, PlannedList etc.)
- [] Pull Requests - We have intensively used the pull request feature in Github, along with the faetures to approve, close pushes, reject, and request changes from the author of the pull request.
- [] Github CLI - half the team used the CLI to perform github actions such as push, pull, checkout to new branches, pull from origin, and to merge branches.
- [] Browse Files from a commit hash - often times, we found ourselves with problems relating to incorrect pushes or pushes where we made errors. This feature helped us to fix our mistaken commits that could have potentially broken the program.
- [] View differences between files - the split difference view helped us thoroughly understand the changes our peers made in commits and pull requests. This helped us understand their changes better, suggest changes, or approve the changes.
- [] Merge Conflict Editor - we used this for some of our pull requests where they were merge conflicts in our .xml files, that were untracked in our .gitignore. Made it easier to instantly solve merge conflicts in merging to main.
- [] .gitignore - we used this to add most of our files in .idea/ and other configuration files into .gitignore to remove these files from tracking. Since we did not need to track changes in these files, adding a .gitignore helped us save time from solving avoidable merge conflict errors.
- [] ![UserRegister Use Case] (https://github.com/CSC207-2022F-UofT/course-project-flipwise-group-129/blob/main/UserRegisterUseCase.jpeg)
- [] ![SettlementPayment Use Case] (https://github.com/CSC207-2022F-UofT/course-project-flipwise-group-129/blob/main/SettlementPayment_Walkthrough.png)
