From ba31588fcb4af5402c4eea927c0764fb0d3d04a7 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Tue, 5 Mar 2024 13:59:45 +0000 Subject: [PATCH] deploy: 139d797ba4cbe08d2bcad8c79c3be0032195856f --- AboutUs.html | 4 ++-- AboutUs.page-vue-render.js | 2 +- Configuration.html | 4 ++-- Configuration.page-vue-render.js | 2 +- DevOps.html | 4 ++-- DevOps.page-vue-render.js | 2 +- DeveloperGuide.html | 6 +++--- DeveloperGuide.page-vue-render.js | 6 +++--- Documentation.html | 4 ++-- Documentation.page-vue-render.js | 2 +- Logging.html | 4 ++-- Logging.page-vue-render.js | 2 +- SettingUp.html | 4 ++-- SettingUp.page-vue-render.js | 2 +- Testing.html | 4 ++-- Testing.page-vue-render.js | 2 +- UserGuide.html | 4 ++-- UserGuide.page-vue-render.js | 2 +- images/Ui.png | Bin 14607 -> 177684 bytes index.html | 4 ++-- index.page-vue-render.js | 2 +- markbind/css/codeblock-dark.min.css | 2 +- markbind/css/markbind.min.css | 2 +- markbind/js/markbind.min.js | 2 +- siteData.json | 2 +- team/johndoe.html | 4 ++-- team/johndoe.page-vue-render.js | 2 +- tutorials/AddRemark.html | 4 ++-- tutorials/AddRemark.page-vue-render.js | 2 +- tutorials/RemovingFields.html | 4 ++-- tutorials/RemovingFields.page-vue-render.js | 2 +- tutorials/TracingCode.html | 4 ++-- tutorials/TracingCode.page-vue-render.js | 2 +- 33 files changed, 49 insertions(+), 49 deletions(-) diff --git a/AboutUs.html b/AboutUs.html index 6bfee73d1d1..def36874726 100644 --- a/AboutUs.html +++ b/AboutUs.html @@ -3,7 +3,7 @@ - + GourmetGrid - About Us - AddressBook Level-3 @@ -24,7 +24,7 @@ [portfolio]

Jane Doe

[github] [portfolio]

Johnny Doe

[github] [portfolio]

Jean Doe

[github] [portfolio]

James Doe

[github] -[portfolio]

+[portfolio]

@@ -19,7 +19,7 @@ Search

Configuration guide

Certain properties of the application can be controlled (e.g user preferences file location, logging level) through the configuration file (default: config.json).

+
  • About Us

    • Configuration guide

    Certain properties of the application can be controlled (e.g user preferences file location, logging level) through the configuration file (default: config.json).

    @@ -21,7 +21,7 @@
  • About Us

    • DevOps guide

    Build automation

    This project uses Gradle for build automation and dependency management. You are recommended to read this Gradle Tutorial from the se-edu/guides.

    Given below are how to use Gradle for some important project tasks.

    Continuous integration (CI)

    This project uses GitHub Actions for CI. The project comes with the necessary GitHub Actions configurations files (in the .github/workflows folder). No further setting up required.

    Code coverage

    As part of CI, this project uses Codecov to generate coverage reports. When CI runs, it will generate code coverage data (based on the tests run by CI) and upload that data to the CodeCov website, which in turn can provide you more info about the coverage of your tests.

    However, because Codecov is known to run into intermittent problems (e.g., report upload fails) due to issues on the Codecov service side, the CI is configured to pass even if the Codecov task failed. Therefore, developers are advised to check the code coverage levels periodically and take corrective actions if the coverage level falls below desired levels.

    To enable Codecov for forks of this project, follow the steps given in this se-edu guide.

    Repository-wide checks

    In addition to running Gradle checks, CI includes some repository-wide checks. Unlike the Gradle checks which only cover files used in the build process, these repository-wide checks cover all files in the repository. They check for repository rules which are hard to enforce on development machines such as line ending requirements.

    These checks are implemented as POSIX shell scripts, and thus can only be run on POSIX-compliant operating systems such as macOS and Linux. To run all checks locally on these operating systems, execute the following in the repository root directory:

    ./config/travis/run-checks.sh

    Any warnings or errors will be printed out to the console.

    If adding new checks:

    Making a release

    Here are the steps to create a new release.

    1. Update the version number in MainApp.java.
    2. Generate a fat JAR file using Gradle (i.e., gradlew shadowJar).
    3. Tag the repo with the version number. e.g. v0.1
    4. Create a new release using GitHub. Upload the JAR file you created.
    +e.g. ./gradlew shadowJar.

  • run: Builds and runs the application.
    runShadow: Builds the application as a fat JAR, and then runs it.

  • checkstyleMain: Runs the code style check for the main code base.
    checkstyleTest: Runs the code style check for the test code base.

  • test: Runs all tests.

    • Continuous integration (CI)

    This project uses GitHub Actions for CI. The project comes with the necessary GitHub Actions configurations files (in the .github/workflows folder). No further setting up required.

    Code coverage

    As part of CI, this project uses Codecov to generate coverage reports. When CI runs, it will generate code coverage data (based on the tests run by CI) and upload that data to the CodeCov website, which in turn can provide you more info about the coverage of your tests.

    However, because Codecov is known to run into intermittent problems (e.g., report upload fails) due to issues on the Codecov service side, the CI is configured to pass even if the Codecov task failed. Therefore, developers are advised to check the code coverage levels periodically and take corrective actions if the coverage level falls below desired levels.

    To enable Codecov for forks of this project, follow the steps given in this se-edu guide.

    Repository-wide checks

    In addition to running Gradle checks, CI includes some repository-wide checks. Unlike the Gradle checks which only cover files used in the build process, these repository-wide checks cover all files in the repository. They check for repository rules which are hard to enforce on development machines such as line ending requirements.

    These checks are implemented as POSIX shell scripts, and thus can only be run on POSIX-compliant operating systems such as macOS and Linux. To run all checks locally on these operating systems, execute the following in the repository root directory:

    ./config/travis/run-checks.sh

    Any warnings or errors will be printed out to the console.

    If adding new checks:

    Making a release

    Here are the steps to create a new release.

    1. Update the version number in MainApp.java.
    2. Generate a fat JAR file using Gradle (i.e., gradlew shadowJar).
    3. Tag the repo with the version number. e.g. v0.1
    4. Create a new release using GitHub. Upload the JAR file you created.
    @@ -19,7 +19,7 @@ Search

    AB-3 Developer Guide

    Acknowledgements

    { list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well }

    Setting up, getting started

    Refer to the guide Setting up and getting started.

    Design

    Architecture

    The Architecture Diagram given above explains the high-level design of the App.

    Given below is a quick overview of main components and how they interact with each other.

    Main components of the architecture

    Main (consisting of classes Main and MainApp) is in charge of the app launch and shut down.

    The bulk of the app's work is done by the following four components:

    Commons represents a collection of classes used by multiple other components.

    How the architecture components interact with each other

    The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command delete 1.

    Each of the four main components (also shown in the diagram above),

    For example, the Logic component defines its API in the Logic.java interface and implements its functionality using the LogicManager.java class which follows the Logic interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.

    The sections below give more details of each component.

    UI component

    The API of this component is specified in Ui.java

    Structure of the UI Component

    The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay, PersonListPanel, StatusBarFooter etc. All these, including the MainWindow, inherit from the abstract UiPart class which captures the commonalities between classes that represent parts of the visible GUI.

    The UI component uses the JavaFx UI framework. The layout of these UI parts are defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

    The UI component,

    Logic component

    API : Logic.java

    Here's a (partial) class diagram of the Logic component:

    The sequence diagram below illustrates the interactions within the Logic component, taking execute("delete 1") API call as an example.

    Interactions Inside the Logic Component for the `delete 1` Command

    Note: The lifeline for DeleteCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline continues till the end of diagram.

    How the Logic component works:

    1. When Logic is called upon to execute a command, it is passed to an AddressBookParser object which in turn creates a parser that matches the command (e.g., DeleteCommandParser) and uses it to parse the command.
    2. This results in a Command object (more precisely, an object of one of its subclasses e.g., DeleteCommand) which is executed by the LogicManager.
    3. The command can communicate with the Model when it is executed (e.g. to delete a person).
      +
  • About Us

    • Gourmet Grid

    Acknowledgements

    { list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well }

    Setting up, getting started

    Refer to the guide Setting up and getting started.

    Design

    Architecture

    The Architecture Diagram given above explains the high-level design of the App.

    Given below is a quick overview of main components and how they interact with each other.

    Main components of the architecture

    Main (consisting of classes Main and MainApp) is in charge of the app launch and shut down.

    The bulk of the app's work is done by the following four components:

    Commons represents a collection of classes used by multiple other components.

    How the architecture components interact with each other

    The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command delete 1.

    Each of the four main components (also shown in the diagram above),

    For example, the Logic component defines its API in the Logic.java interface and implements its functionality using the LogicManager.java class which follows the Logic interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.

    The sections below give more details of each component.

    UI component

    The API of this component is specified in Ui.java

    Structure of the UI Component

    The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay, PersonListPanel, StatusBarFooter etc. All these, including the MainWindow, inherit from the abstract UiPart class which captures the commonalities between classes that represent parts of the visible GUI.

    The UI component uses the JavaFx UI framework. The layout of these UI parts are defined in matching .fxml files that are in the src/main/resources/view folder. For example, the layout of the MainWindow is specified in MainWindow.fxml

    The UI component,

    Logic component

    API : Logic.java

    Here's a (partial) class diagram of the Logic component:

    The sequence diagram below illustrates the interactions within the Logic component, taking execute("delete 1") API call as an example.

    Interactions Inside the Logic Component for the `delete 1` Command

    Note: The lifeline for DeleteCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline continues till the end of diagram.

    How the Logic component works:

    1. When Logic is called upon to execute a command, it is passed to an AddressBookParser object which in turn creates a parser that matches the command (e.g., DeleteCommandParser) and uses it to parse the command.
    2. This results in a Command object (more precisely, an object of one of its subclasses e.g., DeleteCommand) which is executed by the LogicManager.
    3. The command can communicate with the Model when it is executed (e.g. to delete a person).
      Note that although this is shown as a single step in the diagram above (for simplicity), in the code it can take several interactions (between the command object and the Model) to achieve.
    4. The result of the command execution is encapsulated as a CommandResult object which is returned back from Logic.

    Here are the other classes in Logic (omitted from the class diagram above) that are used for parsing a user command:

    How the parsing works:

    Model component

    API : Model.java

    The Model component,

    Note: An alternative (arguably, a more OOP) model is given below. It has a Tag list in the AddressBook, which Person references. This allows AddressBook to only require one Tag object per unique tag, instead of each Person needing their own Tag objects.

    Storage component

    API : Storage.java

    The Storage component,

    Common classes

    Classes used by multiple components are in the seedu.addressbook.commons package.

    Implementation

    This section describes some noteworthy details on how certain features are implemented.

    [Proposed] Undo/redo feature

    Proposed Implementation

    The proposed undo/redo mechanism is facilitated by VersionedAddressBook. It extends AddressBook with an undo/redo history, stored internally as an addressBookStateList and currentStatePointer. Additionally, it implements the following operations:

    These operations are exposed in the Model interface as Model#commitAddressBook(), Model#undoAddressBook() and Model#redoAddressBook() respectively.

    Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.

    Step 1. The user launches the application for the first time. The VersionedAddressBook will be initialized with the initial address book state, and the currentStatePointer pointing to that single address book state.

    UndoRedoState0

    Step 2. The user executes delete 5 command to delete the 5th person in the address book. The delete command calls Model#commitAddressBook(), causing the modified state of the address book after the delete 5 command executes to be saved in the addressBookStateList, and the currentStatePointer is shifted to the newly inserted address book state.

    UndoRedoState1

    Step 3. The user executes add n/David …​ to add a new person. The add command also calls Model#commitAddressBook(), causing another modified address book state to be saved into the addressBookStateList.

    UndoRedoState2

    Note: If a command fails its execution, it will not call Model#commitAddressBook(), so the address book state will not be saved into the addressBookStateList.

    Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undoAddressBook(), which will shift the currentStatePointer once to the left, pointing it to the previous address book state, and restores the address book to that state.

    UndoRedoState3

    Note: If the currentStatePointer is at index 0, pointing to the initial AddressBook state, then there are no previous AddressBook states to restore. The undo command uses Model#canUndoAddressBook() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo.

    The following sequence diagram shows how an undo operation goes through the Logic component:

    UndoSequenceDiagram-Logic

    Note: The lifeline for UndoCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.

    Similarly, how an undo operation goes through the Model component is shown below:

    UndoSequenceDiagram-Model

    The redo command does the opposite — it calls Model#redoAddressBook(), which shifts the currentStatePointer once to the right, pointing to the previously undone state, and restores the address book to that state.

    Note: If the currentStatePointer is at index addressBookStateList.size() - 1, pointing to the latest address book state, then there are no undone AddressBook states to restore. The redo command uses Model#canRedoAddressBook() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.

    Step 5. The user then decides to execute the command list. Commands that do not modify the address book, such as list, will usually not call Model#commitAddressBook(), Model#undoAddressBook() or Model#redoAddressBook(). Thus, the addressBookStateList remains unchanged.

    UndoRedoState4

    Step 6. The user executes clear, which calls Model#commitAddressBook(). Since the currentStatePointer is not pointing at the end of the addressBookStateList, all address book states after the currentStatePointer will be purged. Reason: It no longer makes sense to redo the add n/David …​ command. This is the behavior that most modern desktop applications follow.

    UndoRedoState5

    The following activity diagram summarizes what happens when a user executes a new command:

    Design considerations:

    Aspect: How undo & redo executes:

    {more aspects and alternatives to be added}

    [Proposed] Data archiving

    {Explain here how the data archiving feature will be implemented}

    Documentation, logging, testing, configuration, dev-ops

    Appendix: Requirements

    Product scope

    Target user profile:

    Value proposition: manage contacts faster than a typical mouse/GUI driven app

    User stories

    Priorities: High (must have) - * * *, Medium (nice to have) - * *, Low (unlikely to have) - *

    Priority As a …​ I want to …​ So that I can…​
    * * * new user see usage instructions refer to instructions when I forget how to use the App
    * * * user add a new person
    * * * user delete a person remove entries that I no longer need
    * * * user find a person by name locate details of persons without having to go through the entire list
    * * user hide private contact details minimize chance of someone else seeing them by accident
    * user with many persons in the address book sort persons by name locate a person easily

    {More to be added}

    Use cases

    (For all use cases below, the System is the AddressBook and the Actor is the user, unless specified otherwise)

    Use case: Delete a person

    MSS

    1. User requests to list persons

    2. AddressBook shows a list of persons

    3. User requests to delete a specific person in the list

    4. AddressBook deletes the person

      Use case ends.

    Extensions

    {More to be added}

    Non-Functional Requirements

    1. Should work on any mainstream OS as long as it has Java 11 or above installed.
    2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
    3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.

    {More to be added}

    Glossary

    Appendix: Instructions for manual testing

    Given below are instructions to test the app manually.

    Note: These instructions only provide a starting point for testers to work on; @@ -27,7 +27,7 @@ Expected: The most recent window size and location is retained.

  • { more test cases …​ }

    • Deleting a person

    1. Deleting a person while all persons are being shown

      1. Prerequisites: List all persons using the list command. Multiple persons in the list.

      2. Test case: delete 1
        Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated.

      3. Test case: delete 0
        Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.

      4. Other incorrect delete commands to try: delete, delete x, ... (where x is larger than the list size)
        -Expected: Similar to previous.

    2. { more test cases …​ }

    Saving data

    1. Dealing with missing/corrupted data files

      1. {explain how to simulate a missing/corrupted file, and the expected behavior}

    2. { more test cases …​ }

    [Powered by MarkBind 5.2.0, generated on Tue, 13 Feb 2024, 22:56:21 GMT+8]
    +Expected: Similar to previous.

  • { more test cases …​ }

    • Saving data

    1. Dealing with missing/corrupted data files

      1. {explain how to simulate a missing/corrupted file, and the expected behavior}

    2. { more test cases …​ }

    @@ -19,7 +19,7 @@ Search

    Documentation Guide

    Style guidance:

    Converting to PDF

    +
  • About Us

    • Documentation Guide

    Style guidance:

    Converting to PDF

    @@ -19,7 +19,7 @@ Search

    Logging guide

    +
  • About Us

    • Logging guide

    @@ -25,7 +25,7 @@
  • Verify the setup:
    1. Run the seedu.address.Main and try a few commands.
    2. Run the tests to ensure they all pass.

    • Before writing code

    1. Configure the coding style

      If using IDEA, follow the guide [se-edu/guides] IDEA: Configuring the code style to set up IDEA's coding style to match ours.

      Tip: Optionally, you can follow the guide [se-edu/guides] Using Checkstyle to find how to use the CheckStyle within IDEA e.g., to report problems as you write code.

    2. Set up CI

      This project comes with a GitHub Actions config files (in .github/workflows folder). When GitHub detects those files, it will run the CI for your project automatically at each push to the master branch or to any PR. No set up required.

    3. Learn the design

      When you are ready to start coding, we recommend that you get some sense of the overall design by reading about AddressBook’s architecture.

    4. Do the tutorials -These tutorials will help you get acquainted with the codebase.

    +These tutorials will help you get acquainted with the codebase.

    @@ -23,7 +23,7 @@ test class, or a test and choose Run 'ABC'
  • Method 2: Using Gradle

    • Link: Read this Gradle Tutorial from the se-edu/guides to learn more about using Gradle.

    Types of tests

    This project has three types of tests:

    1. Unit tests targeting the lowest level methods/classes.
      e.g. seedu.address.commons.StringUtilTest
    2. Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
      e.g. seedu.address.storage.StorageManagerTest
    3. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
      -e.g. seedu.address.logic.LogicManagerTest
    +e.g. seedu.address.logic.LogicManagerTest @@ -30,7 +30,7 @@ specifying any tags after it.

    Examples:

    Locating persons by name: find

    Finds persons whose names contain any of the given keywords.

    Format: find KEYWORD [MORE_KEYWORDS]

    Examples:

    Deleting a person : delete

    Deletes the specified person from the address book.

    Format: delete INDEX

    Examples:

    Clearing all entries : clear

    Clears all entries from the address book.

    Format: clear

    Exiting the program : exit

    Exits the program.

    Format: exit

    Saving the data

    AddressBook data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.

    Editing the data file

    AddressBook data are saved automatically as a JSON file [JAR file location]/data/addressbook.json. Advanced users are welcome to update data directly by editing that data file.

    Caution: If your changes to the data file makes its format invalid, AddressBook will discard all data and start with an empty data file at the next run. Hence, it is recommended to take a backup of the file before editing it.
    -Furthermore, certain edits can cause the AddressBook to behave in unexpected ways (e.g., if a value entered is outside the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.

    Archiving data files [coming in v2.0]

    Details coming soon ...

    FAQ

    Q: How do I transfer my data to another Computer?
    A: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder.

    Known issues

    1. When using multiple screens, if you move the application to a secondary screen, and later switch to using only the primary screen, the GUI will open off-screen. The remedy is to delete the preferences.json file created by the application before running the application again.

    Command summary

    Action Format, Examples
    Add add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…​
    e.g., add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague
    Clear clear
    Delete delete INDEX
    e.g., delete 3
    Edit edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…​
    e.g.,edit 2 n/James Lee e/jameslee@example.com
    Find find KEYWORD [MORE_KEYWORDS]
    e.g., find James Jake
    List list
    Help help
    +Furthermore, certain edits can cause the AddressBook to behave in unexpected ways (e.g., if a value entered is outside the acceptable range). Therefore, edit the data file only if you are confident that you can update it correctly.

    Archiving data files [coming in v2.0]

    Details coming soon ...

    FAQ

    Q: How do I transfer my data to another Computer?
    A: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder.

    Known issues

    1. When using multiple screens, if you move the application to a secondary screen, and later switch to using only the primary screen, the GUI will open off-screen. The remedy is to delete the preferences.json file created by the application before running the application again.

    Command summary

    Action Format, Examples
    Add add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…​
    e.g., add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague
    Clear clear
    Delete delete INDEX
    e.g., delete 3
    Edit edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…​
    e.g.,edit 2 n/James Lee e/jameslee@example.com
    Find find KEYWORD [MORE_KEYWORDS]
    e.g., find James Jake
    List list
    Help help
    @@ -19,7 +19,7 @@ Search

    AddressBook Level-3

    CI Status codecov

    Ui

    AddressBook is a desktop application for managing your contact details. While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface).

    Acknowledgements

    +
  • About Us

    • AddressBook Level-3

    CI Status codecov

    Ui

    AddressBook is a desktop application for managing your contact details. While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface).

    Acknowledgements

    @@ -21,7 +21,7 @@
  • About Us

    • Project: AddressBook Level 3

    AddressBook - Level 3 is a desktop address book application used for teaching Software Engineering principles. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 10 kLoC.

    Given below are my contributions to the project.

    +

  • Community:

  • Tools:

  • {you can add/remove categories in the list above}

    • @@ -174,7 +174,7 @@ return String.format(message, personToEdit); }

    Congratulations!

    Writing tests

    Tests are crucial to ensuring that bugs don’t slip into the codebase unnoticed. This is especially true for large code bases where a change might lead to unintended behavior.

    Let’s verify the correctness of our code by writing some tests!

    Of course you can simply add the test cases manually, like you've been doing all along this tutorial. The result would be like the test cases in here. Alternatively, you can get the help of IntelliJ to generate the skeletons of the test cases, as explained in the next section.

    Automatically generating tests

    The goal is to write effective and efficient tests to ensure that RemarkCommand#execute() behaves as expected.

    The convention for test names is methodName_testScenario_expectedResult. An example would be -execute_filteredList_success.

    Let’s create a test for RemarkCommand#execute() to test that adding a remark works. On IntelliJ IDEA you can bring up the context menu and choose to Go To > Test or use the appropriate keyboard shortcut.

    Using the context menu to jump to tests

    Then, create a test for the execute method.

    Creating a test for `execute`.

    Following convention, let’s change the name of the generated method to execute_addRemarkUnfilteredList_success.

    Let’s use the utility functions provided in CommandTestUtil. The functions ensure that commands produce the expected CommandResult and output the correct message. In this case, CommandTestUtil#assertCommandSuccess is the best fit as we are testing that a RemarkCommand will successfully add a Remark.

    You should end up with a test that looks something like this.

    Conclusion

    This concludes the tutorial for adding a new Command to AddressBook.

    +execute_filteredList_success.

    Let’s create a test for RemarkCommand#execute() to test that adding a remark works. On IntelliJ IDEA you can bring up the context menu and choose to Go To > Test or use the appropriate keyboard shortcut.

    Using the context menu to jump to tests

    Then, create a test for the execute method.

    Creating a test for `execute`.

    Following convention, let’s change the name of the generated method to execute_addRemarkUnfilteredList_success.

    Let’s use the utility functions provided in CommandTestUtil. The functions ensure that commands produce the expected CommandResult and output the correct message. In this case, CommandTestUtil#assertCommandSuccess is the best fit as we are testing that a RemarkCommand will successfully add a Remark.

    You should end up with a test that looks something like this.

    Conclusion

    This concludes the tutorial for adding a new Command to AddressBook.

    @@ -39,7 +39,7 @@ "address": "4th street" } ] } -

    You can go through each individual json file and manually remove the address field.

    +

    You can go through each individual json file and manually remove the address field.

    @@ -104,7 +104,7 @@ do you think will happen if we traced the following commands instead? What exceptions do you think will be thrown (if any), where will the exceptions be thrown and where will they be handled?

    1. redit 1 n/Alice Yu

    2. edit 0 n/Alice Yu

    3. edit 1 n/Alex Yeoh

    4. edit 1

    5. edit 1 n/アリス ユー

    6. edit 1 t/one t/two t/three t/one

  • What components will you have to modify to perform the following -enhancements to the application?

    1. Make command words case-insensitive

    2. Allow delete to remove more than one index at a time

    3. Save the address book in the CSV format instead

    4. Add a new command

    5. Add a new field to Person

    6. Add a new entity to the address book

    • +enhancements to the application?

    1. Make command words case-insensitive

    2. Allow delete to remove more than one index at a time

    3. Save the address book in the CSV format instead

    4. Add a new command

    5. Add a new field to Person

    6. Add a new entity to the address book