nus-cs2103-AY2223S2 / forum

12 stars 0 forks source link

Randomising test cases, is this fine? #295

Open sumhungyee opened 1 year ago

sumhungyee commented 1 year ago

Hey @damithc prof, I'm implementing an undo/redo functionality for my tp and I'm basically storing denguehotspottracker objects in a modified stack. For my test cases i create a few randomised denguehotspottracker objects (random number of random people) and place them into the stack. I then perform undo, redo and save to try to break the system. (So this part is deterministic.) Is this an okay way of testing?

Basically my idea is I'm testing the data structure, so i think it should be fine if the dht's are random?

damithc commented 1 year ago

Basically my idea is I'm testing the data structure, so i think it should be fine if the dht's are random?

@sumhungyee Yes, if tests are not affected by the data, it shouldn't matter if they are generated randomly. But then, if the data doesn't matter to the test case, why not use fixed dummy data instead of generating them randomly? Is there a good reason for using random data?

sumhungyee commented 1 year ago

@damithc Thanks for replying prof. I personally felt at that time that it was better to test more generally, because whenever i perform a change to the ab3 (my mistake, i said dht) and save it to the stack, the change could come in the form of a delete or edit, or something else. But what i really want is to save previous iterations of my ab3, whatever the change results from delete, edit or something else.

So creating random ab3s really makes the problem clear, that no matter what changes have been made, I'm saving them in the stack.

Also there isn't a lot of dummy data to go around :/

damithc commented 1 year ago

I see. Anyway, it's your team's decision. There is no objections to either approach from a tP requirements point of view.

On a related note, you may want to make a record of the random data used for the test. Reason: if a test fails suddenly, you might want to know exactly what data was used in the test, just in case the failure was related to the data (although the behavior under test is not supposed to be affected by the data -- that assumption may not hold if there is a bug in the related code).