Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#11572] Notification: GET API test and access control #11648

Conversation

ziqing26
Copy link
Contributor

@ziqing26 ziqing26 commented Mar 14, 2022

Part of #11572

Outline of Solution

  • Add tests for NotificationAttributes
  • Add notifications to typical data bundle
  • Add tests for GET API

Has not include:

  • isfetchingall related feature / tests.

@ziqing26 ziqing26 force-pushed the 11572-test-notification-get-api branch from 2d962e6 to 8e13258 Compare March 18, 2022 07:11
@ziqing26 ziqing26 marked this pull request as ready for review March 18, 2022 07:11
@TEAMMATES TEAMMATES deleted a comment from teammates-bot Mar 18, 2022
@TEAMMATES TEAMMATES deleted a comment from teammates-bot Mar 18, 2022
@TEAMMATES TEAMMATES deleted a comment from teammates-bot Mar 18, 2022
@TEAMMATES TEAMMATES deleted a comment from teammates-bot Mar 18, 2022
@ziqing26 ziqing26 added the s.ToReview The PR is waiting for review(s) label Mar 19, 2022
Copy link
Contributor

@jianhandev jianhandev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good test coverage!

src/test/resources/data/typicalDataBundle.json Outdated Show resolved Hide resolved
Comment on lines 93 to 95
______TS("Request to fetch notification");
int expectedNumberOfNotifications = 4;
InstructorAttributes instructor = typicalBundle.instructors.get("instructor1OfCourse1");
Copy link
Contributor

@jianhandev jianhandev Mar 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The expected number of active notifications here is dependent on the current time, we are in 2022 but two years later the end time for some of these notifications e.g. notification-4 would have passed, then this test will fail 😄 .

    "notification-4": {
      "notificationId": "notification-4",
      "startTime": "2011-04-04T00:00:00Z",
      "endTime": "2024-04-04T00:00:00Z",
      "createdAt": "2011-01-01T00:00:00Z",
      "updatedAt": "2011-01-01T00:00:00Z",
      "type": "MAINTENANCE",
      "targetUser": "GENERAL",
      "title": "The note of maintenance",
      "message": "The content of maintenance",
      "shown": false
    },

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be okay if I change the endtime to for example 2099?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be okay if I change the endtime to for example 2099?

This has been updated in the newly pushed code. Thank you!

Comment on lines 16 to 27
private static final Instant STARTTIME_ONE = Instant.now().plusSeconds(3600);
private static final Instant ENDTIME_ONE = Instant.now().plusSeconds(7200);
private static final Instant STARTTIME_TWO = Instant.now().plusSeconds(1000);
private static final Instant ENDTIME_TWO = Instant.now().plusSeconds(10000);

@Test
public void testValueOf_withAllFieldPopulatedNotificationAttributes_shouldGenerateAttributesCorrectly() {
Notification notification = new Notification("valid-notification-id",
STARTTIME_ONE, ENDTIME_ONE,
NotificationType.DEPRECATION, NotificationTargetUser.INSTRUCTOR,
"valid notification title", "valid notification message", false,
Instant.now(), Instant.now());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these data are going to be used frequently across different tests, you may want to use a helper method like generateTypicalNotificationAttributesObject to generate a NotificationAttributes object for you and reuse them across tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The builder might have slight variations in certain fields and in numbers of fields. If we abstract a method out for that, my concern is it will become just a wrapper around the builder, which might not be necessary.

Copy link
Contributor

@jianhandev jianhandev Mar 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for cases where we need to test with different values we can build the NotificationAttributes separately, but for typical NotificationAttributes we can use a helper method method like generateTypicalNotificationAttributesObject to improve readability.

I have highlighted a few examples below, there are many others places where we can simply call generateTypicalNotificationAttributesObject to generate a default NotificationAttributes for us.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the suggestion! I have changed accordingly in the new commit.

@jianhandev jianhandev added s.Ongoing The PR is being worked on by the author(s) and removed s.ToReview The PR is waiting for review(s) labels Mar 22, 2022
@ziqing26 ziqing26 added s.ToReview The PR is waiting for review(s) and removed s.Ongoing The PR is being worked on by the author(s) labels Mar 22, 2022
@ziqing26
Copy link
Contributor Author

@jianhandev In the new commit, I add methods in NotificationAttributesTest to abstract the creation of typical attributes and remove declaration of Instant variables. Meanwhile I have also added tests for FieldValidator as that was missing previously. Thank you for your help!

Comment on lines 651 to 653
String notificationType = "invalid type";
assertEquals("\"invalid type\" is not an accepted notification type to TEAMMATES. ",
FieldValidator.getInvalidityInfoForNotificationType(notificationType));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
String notificationType = "invalid type";
assertEquals("\"invalid type\" is not an accepted notification type to TEAMMATES. ",
FieldValidator.getInvalidityInfoForNotificationType(notificationType));
String notificationType = "invalid type";
assertEquals(notificationType + " is not an accepted notification type to TEAMMATES. ",
FieldValidator.getInvalidityInfoForNotificationType(notificationType));

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error messages have double quotes around the variable. So we might still need to keep the \" there.

Comment on lines 664 to 666
String user = "invalid user";
assertEquals("\"invalid user\" is not an accepted notification target user to TEAMMATES. ",
FieldValidator.getInvalidityInfoForNotificationTargetUser(user));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
String user = "invalid user";
assertEquals("\"invalid user\" is not an accepted notification target user to TEAMMATES. ",
FieldValidator.getInvalidityInfoForNotificationTargetUser(user));
String invalidUser = "invalid user";
assertEquals(invalidUser + " is not an accepted notification target user to TEAMMATES. ",
FieldValidator.getInvalidityInfoForNotificationTargetUser(invalidUser));

@jianhandev jianhandev merged commit 2934849 into TEAMMATES:notification-feature Mar 22, 2022
fsgmhoward pushed a commit that referenced this pull request Apr 1, 2022
* Add test for NotificationAttributes

* Add notifications to typicalDataBundles and init GET api test

* Add tests for GET api

* Add access control and its tests for GET api

* Update data in dataBundle and add more abstractions

* Refactor NotificationAttributesTest and add tests for FieldValidator
fsgmhoward pushed a commit that referenced this pull request Apr 1, 2022
* Add test for NotificationAttributes

* Add notifications to typicalDataBundles and init GET api test

* Add tests for GET api

* Add access control and its tests for GET api

* Update data in dataBundle and add more abstractions

* Refactor NotificationAttributesTest and add tests for FieldValidator
jianhandev pushed a commit that referenced this pull request Apr 5, 2022
* Add test for NotificationAttributes

* Add notifications to typicalDataBundles and init GET api test

* Add tests for GET api

* Add access control and its tests for GET api

* Update data in dataBundle and add more abstractions

* Refactor NotificationAttributesTest and add tests for FieldValidator
jianhandev pushed a commit that referenced this pull request Apr 5, 2022
* Add test for NotificationAttributes

* Add notifications to typicalDataBundles and init GET api test

* Add tests for GET api

* Add access control and its tests for GET api

* Update data in dataBundle and add more abstractions

* Refactor NotificationAttributesTest and add tests for FieldValidator
jianhandev pushed a commit that referenced this pull request Apr 6, 2022
* Add test for NotificationAttributes

* Add notifications to typicalDataBundles and init GET api test

* Add tests for GET api

* Add access control and its tests for GET api

* Update data in dataBundle and add more abstractions

* Refactor NotificationAttributesTest and add tests for FieldValidator
jianhandev pushed a commit that referenced this pull request Apr 6, 2022
* Add test for NotificationAttributes

* Add notifications to typicalDataBundles and init GET api test

* Add tests for GET api

* Add access control and its tests for GET api

* Update data in dataBundle and add more abstractions

* Refactor NotificationAttributesTest and add tests for FieldValidator
@wkurniawan07 wkurniawan07 added s.ToMerge The PR is approved by all reviewers including final reviewer; ready for merging c.Task Other non-user-facing works, e.g. refactoring, adding tests and removed s.ToReview The PR is waiting for review(s) labels Apr 6, 2022
@wkurniawan07 wkurniawan07 added this to the V8.13.0 milestone Apr 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c.Task Other non-user-facing works, e.g. refactoring, adding tests s.ToMerge The PR is approved by all reviewers including final reviewer; ready for merging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants