5

I ran across this situation this afternoon, so I thought I'd ask what you guys do.

We have a randomized password generator for user password resets and while fixing a problem with it, I decided to move the routine into my (slowly growing) test harness.

I want to test that passwords generated conform to the rules we've set out, but of course the results of the function will be randomized (or, well, pseudo-randomized).

What would you guys do in the unit test? Generate a bunch of passwords, check they all pass and consider that good enough?

Peter O.
  • 32,158
  • 14
  • 82
  • 96
Dana
  • 32,083
  • 17
  • 62
  • 73
  • Possible duplicate of [Unit Testing with functions that return random results](http://stackoverflow.com/questions/311807/unit-testing-with-functions-that-return-random-results) – Raedwald Jan 23 '16 at 15:50

11 Answers11

8

A unit test should do the same thing every time that it runs, otherwise you may run into a situation where the unit test only fails occasionally, and that could be a real pain to debug.

Try seeding your pseudo-randomizer with the same seed every time (in the test, that is--not in production code). That way your test will generate the same set of inputs every time.

If you can't control the seed and there is no way to prevent the function you are testing from being randomized, then I guess you are stuck with an unpredictable unit test. :(

Parappa
  • 7,566
  • 3
  • 34
  • 38
  • @Parappa: you could always run the random code enough times to be certain you've covered all of your bases with some alpha. – user7116 Sep 17 '08 at 22:06
  • 1
    Also make sure that if the test fails that all parameters at the time are logged so one might be able to see why it failed. Being able to have a known or constant seed, etc. will be the big thing though. – Kris Kumler Sep 17 '08 at 22:36
4

The function is a hypothesis that for all inputs, the output conforms to the specifications. The unit test is an attempt to falsify that hypothesis. So yes, the best you can do in this case is to generate a large amount of outputs. If they all pass your specification, then you can be reasonably sure that your function works as specified.

Consider putting the random number generator outside this function and passing a random number to it, making the function deterministic, instead of having it access the random number generator directly. This way, you can generate a large number of random inputs in your test harness, pass them all to your function, and test the outputs. If one fails, record what that value is so that you have a documented test case.

Apocalisp
  • 34,834
  • 8
  • 106
  • 155
2

In addition to testing a few to make sure that they pass, I'd write a test to make sure that passwords that break the rules fail.

Is there anything in the codebase that's checking the passwords generated to make sure they're random enough? If not, I may look at creating the logic to check the generated passwords, testing that, and then you can state that the random password generator is working (as "bad" ones won't get out).

Once you've got that logic you can probably write an integration type test that would generate boatloads of passwords and pass it through the logic, at which point you'd get an idea of how "good" your random password generate is.

shelfoo
  • 1,569
  • 13
  • 15
0

Either use fixed random seed or make it reproducible (i.e.: derive from the current day)

Rinat Abdullin
  • 23,036
  • 8
  • 57
  • 80
0

Firstly, use a seed for your PRNG. Your input is no longer random and gets rid of the problem of unpredictable output - i.e. now your unit test is deterministic.

This doesn't however solve the problem of testing the implementation, but here is an example of how a typical method that relies upon randomness can be tested.

Imagine we've implemented a function that takes a collection of red and blue marbles and picks one at random, but a weighting can be assigned to the probability, i.e. weights of 2 and 1 would mean red marbles are twice as likely to be picked as blue marbles.

We can test this by setting the weight of one choice to zero and verifying that in all cases (in practice, for a large amount of test input) we always get e.g. blue marbles. Reversing the weights should then give the opposite result (all red marbles).

This doesn't guarantee our function is behaving as intended (if we pass in an equal number of red and blue marbles and have equal weights do we always get a 50/50 distribution over a large number of trials?) but in practice it is often sufficient.

ganonm
  • 1
0

Well, considering they are random, there is no really way to make sure, but testing for 100 000 password should clear most doubts :)

Sklivvz
  • 30,601
  • 24
  • 116
  • 172
0

You can also look into mutation testing (Jester for Java, Heckle for Ruby)

Aeon
  • 6,467
  • 5
  • 29
  • 31
0

You could seed your random number generator with a constant value in order to get non-random results and test those results.

Bradley Harris
  • 922
  • 1
  • 6
  • 12
0

I'm assuming that the user-entered passwords conform to the same restrictions as the random generated ones. So you probably want to have a set of static passwords for checking known conditions, and then you'll have a loop that does the dynamic password checks. The size of the loop isn't too important, but it should be large enough that you get that warm fuzzy feeling from your generator, but not so large that your tests take forever to run. If anything crops up over time, you can add those cases to your static list.

In the long run though, a weak password isn't going to break your program, and password security falls in the hands of the user. So your priority would be to make sure that the dynamic generation and strength-check doesn't break the system.

Glenn
  • 200
  • 1
  • 2
  • 6
0

Without knowing what your rules are it's hard to say for sure, but assuming they are something like "the password must be at least 8 characters with at least one upper case letter, one lower case letter, one number and one special character" then it's impossible even with brute force to check sufficient quantities of generated passwords to prove the algorithm is correct (as that would require somewhere over 8^70 = 1.63x10^63 checks depending on how many special characters you designate for use, which would take a very, very long time to complete).

Ultimately all you can do is test as many passwords as is feasible, and if any break the rules then you know the algorithm is incorrect. Probably the best thing to do is leave it running overnight, and if all is well in the morning you're likely to be OK.

If you want to be doubly sure in production, then implement an outer function that calls the password generation function in a loop and checks it against the rules. If it fails then log an error indicating this (so you know you need to fix it) and generate another password. Continue until you get one that meets the rules.

Greg Beech
  • 133,383
  • 43
  • 204
  • 250
0

In my humble opinion you do not want a test that sometimes pass and sometimes fails. Some people may even consider that this kind of test is not a unit test. But the main idea is be sure that the function is OK when you see the green bar.

With this principle in mind you may try to execute it a reasonable number of times so that the chance of having a false correct is almost cero. However, une single failure of the test will force you to make more extensive tests apart from debbuging the failure.

borjab
  • 11,149
  • 6
  • 71
  • 98