I'd check the things you can know. Such as, if you ran the same method twice then it should result in two arrays of the same size that contain all the same things, but that aren't equal, i.e. the order is different.
I tried another thing recently where I needed to create a random string as output. I used dependency injection for the randomiser function with a default to the built in language version. Then in my test, I used a deterministic object for the randomiser function, such that I knew what the output was. I wasn't implementing the actual randomiser function, so testing it is not necessary, but testing that I'd call the right method on it and it returned the thing I expected satisfied me at the time.
f.e. I have 3 elements in my array, [1, 2, 3]. Now the shuffle method only has six outcomes here, so there is a real possibility that the tests might randomly fail even if the code is correct.
Dependency injection seems like a better approach if you want to test it, but it makes code not as nice to read.
Aye, that's true. I was kind of thinking about it in terms of generating an array of 10000 items!
Writing testable code is a trade off, but probably worthwhile in the long run. Dependency injection itself makes for more and more flexible code without a great deal of extra cognitive overload, so I am a big fan of it at the moment.
I'd check the things you can know. Such as, if you ran the same method twice then it should result in two arrays of the same size that contain all the same things, but that aren't equal, i.e. the order is different.
I tried another thing recently where I needed to create a random string as output. I used dependency injection for the randomiser function with a default to the built in language version. Then in my test, I used a deterministic object for the randomiser function, such that I knew what the output was. I wasn't implementing the actual randomiser function, so testing it is not necessary, but testing that I'd call the right method on it and it returned the thing I expected satisfied me at the time.
Just some ideas.
But wouldn't this fail at times?
f.e. I have 3 elements in my array,
[1, 2, 3]. Now the shuffle method only has six outcomes here, so there is a real possibility that the tests might randomly fail even if the code is correct.Dependency injection seems like a better approach if you want to test it, but it makes code not as nice to read.
Trade-offs I suppose.
Aye, that's true. I was kind of thinking about it in terms of generating an array of 10000 items!
Writing testable code is a trade off, but probably worthwhile in the long run. Dependency injection itself makes for more and more flexible code without a great deal of extra cognitive overload, so I am a big fan of it at the moment.
This was a great talk from Sandy Metz that drove towards this point for a different reason too. I recommend a watch!