Thread: [Kotlin] Random Permutation

Originally Posted by Gluon

To ensure that its actually generating a unique set of random indices that cover the entire scope of the array/collection you're using them on. That no indices are missing/duplicated/wrong.

Why did you stop at 1000?

Originally Posted by Tyluur

Why did you stop at 1000?

I can invite you to the repo so you can cover each test 1->2^31-1 for me

Originally Posted by Gluon

I can invite you to the repo so you can cover each test 1->2^31-1 for me

My discord is in my postbit thing

You could most likely parametrize the tests so you dont have 10 different test cases instead a single test case with multiple params. Other than that seems cool

[Only registered and activated users can see links. ]

Edit:

Why are you testing constants lol? Unit tests are meant to test a single unit of your OWN functionality not if kotlin adheres to keeping a constant a constant :\:

Code:

   @[Only registered and activated users can see links. ]
	fun testConstants() {
		assertEquals(1_0_1_3_9_0_4_2_2_3, RandomPermutation.c)
		assertEquals(1_6_6_4_5_2_5, RandomPermutation.a)
	}

Originally Posted by Tyluur

My discord is in my postbit thing

Doesn't work. Add me Gluon#3992

Originally Posted by Gluon

Doesn't work. Add me Gluon#3992

Adding. Prob cuz we’re on vb4 and not xenforo.

Originally Posted by JayArrowz

You could most likely parametrize the tests so you dont have 10 different test cases instead a single test case with multiple params. Other than that seems cool

[Only registered and activated users can see links. ]

Edit:

Why are you testing constants lol? Unit tests are meant to test a single unit of your OWN functionality not if kotlin adheres to keeping a constant a constant :\:

Code:

   @[Only registered and activated users can see links. ]
	fun testConstants() {
		assertEquals(1_0_1_3_9_0_4_2_2_3, RandomPermutation.c)
		assertEquals(1_6_6_4_5_2_5, RandomPermutation.a)
	}

Because I accidentally replaced them once when doing a server wide Ctrl + Shift + R to replace some hardcoded packet id and couldn't figure out why my pid wasn't shuffling properly lmfao. Those values need to be those exact values so doesn't hurt to test them to ensure they haven't changed.

Originally Posted by Gluon

Because I accidentally replaced them once when doing a server wide Ctrl + Shift + R to replace some hardcoded packet id and couldn't figure out why my pid wasn't shuffling properly lmfao. Those values need to be those exact values so doesn't hurt to test them to ensure they haven't changed.

This is the same energy that started project insanity.

Originally Posted by Gluon

Because I accidentally replaced once them when doing a server wide Ctrl + Shift + R to replace some hardcoded packet id and couldn't figure out why my pid wasn't shuffling properly lmfao. Those values need to be those exact values so doesn't hurt to test them to ensure they haven't changed.

Fair I guess its a benefit then, for example, if someone's CI stops a person from committing a PR due to the testConstants unit test failing then atleast the dev knows that they changed a value they shouldn't have.