TS: Test more modes about john-tests HOT 8 OPEN

descrypt and dummy would also be a good choice:
Both are core formats, stable, well tested.
One of them is salted, the other isn't.

from john-tests.

Actually we could be smarter than saying "500", "1500" and "150000". We could use eg. 2xMKPC, 48xMKPC and 48,000xMPKC so for NT (mkpc=32) we'd pick the first 64 words plus 1536 more, out of 1,5 million words.

This would mean we auto-adjust to eg. OpenCL formats with huge batches.

from john-tests.

I prefer NT over dummy because it lets us verify thread-safety in Unicode functions too. But for testing core we could use dummy.

EDIT NT has its own Unicode functions... so we may want to support some other format as well.

from john-tests.

There was Inc at one time, but the char files changed. The script does an msg of the chr file and will not continue if it does not match. Since they changed the script no longer uses them.

from john-tests.

That why I propose to create the test files on the fly. For these few formats, jtrts.dat can include the necessary functions to create the hashes. There's no point in testing incremental with all 300 formats. It would just take a lot of time.

from john-tests.

But if the process being tested is producing the test cases, does that not scream invalid?

from john-tests.

That's true, in many cases. I was mostly thinking about fork/mpi/node tests. The test file should be produced with neither of those options. We'd also test many things in cracker.c and loader.c that is not really used in the --inc --stdout that produces the files. BTW we could also test --resume this way (perhaps starting with --max-runtime).

But yes, maybe we should keep the thing you have in there, but update it with 1.8.0 incremental too.

from john-tests.

#56 added resume tests, which includes basic mode tests.

from john-tests.