chewterence / pe

0 stars 0 forks source link

Done command shows invalid command format for large indexes instead of #3

Open chewterence opened 3 years ago

chewterence commented 3 years ago

Steps to reproduce: done 999999999999999999999999999999

Instead of:

image.png

It shows:

image.png

nus-pe-bot commented 3 years ago

Team's Response

No response provided.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Long index for deleteTask shows invalid command format instead of

Steps to reproduce: where there is only < 10 tasks deleteTask 99999999999999999

Instead of showing "task index provided is invalid":

image.png

It shows this:

image.png


[original: nus-cs2103-AY2021S2/pe-interim#1716] [original labels: severity.Medium type.FunctionalityBug]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

All the issues and duplicates arise as a result of an index above MAX_INT in java being given, resulting in the command format message appearing instead of the invalid index message.

This message appearing is a result of a constraint in the java programming language. We felt that would be too time intensive and requires too much effort for the team to look into a solution that handles the constraint of the java programming language given the endless possibilities a user can input as the index e.g. User can put in 20, 50, 100 digits as the index as well as the erratic/unpredictable outcome of having such a number being input.

Furthermore, we do not expect our users to have that many tasks stored concurrently in the app at once to refer to a task with index above MAX_INT, as this would make the app unusable. As stated in the DG, we expect the app to be able to perform normally up to 100 members and tasks. Thus we do not explicitly handle this edge case of such a high value index (above MAX_INT) and we do not believe this is a real issue users will come across, as they will not even come close to inputting such values as an index in the actual usage of our app.

Thus we are classifying this under Not in scope, taking into the consideration the issue does not result in the app crashing as well as the constraints of the programming language used and the constraints of our app (as specified, the app is not designed to handle more than 100 members and tasks concurrently), we believe this error message is acceptable.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: This should be considered as a different bug than its claimed "duplicates". Each of these errors is not handled in different commands, and thus should be counted as different bugs.


:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Thank you for the very detailed response.

Claiming this bug as:

"a result of a constraint in the java programming language" "be too time intensive and requires too much effort for the team to look into a solution that handles the constraint of the java programming language given the endless possibilities a user can input" is a fallacy.

The role of a software engineer is to ensure that even errors such as these under the constraints of the programming language are handled properly, then your software will truly be bug-free. Limitations of the programming language are something that users of the software should not be concerned about.

Moreover, this has shown that equivalence partitioning testing that was taught to us in this module, was even not performed as a test. Consequently, this and other bugs that I have reported have surfaced due to the lack of equivalence partitioning testing.

Although the severity should be "Low", I believe that this bug should be accepted.