Property testing
Recall from lecture that:
Property testing is a testing technique [...] where we:
- randomly select test inputs,
- assert general properties that are automatically verifiable on test input/output pairs,
- verify that properties hold on the obtained test input/output pairs.
You are going to use the proptest crate to verify some properties about the accountmgr crate.
Add proptest as a development dependency to your crate with cargo add --dev proptest; doing so will make your package only conditionally depend on protest, specifically when compiling tests, examples, and benchmarks.
Verify within Cargo.toml that the dependencies has indeed been added under the [dev-dependencies] section.
Exercise 3.a:
Add a new unit test to those already present in your lib.rs module, which randomizes the parse string so that only valid account strings are formed (e.g., you can start with a simple regex like r"[a-z]*:[a-z]*" representing letters followed by a colon followed by letters, and then improve it to be more "nasty" by adding other special characters).
Note that the new test will need to be put within a proptest! environment.
Add an assertion to verify that the account string is properly parsed (i.e., that parse_account does not return an error).
Here are some useful references about proptest: crate, documentation, book.
Let's now strengthen our parsing requirements, because accounts with empty usernames and/or passwords are no good, right?
Exercise 3.b:
Change your parse_account function so that it refuses accounts strings containing empty username and/or passwords.
Run your unit tests again. proptest tests should catch the fact that empty usernames/passwords are no longer correctly parsed and give you examples of account strings that fail.
Improve your proptest regex so that only (new) valid account strings are produced.
Add specific (non-random) unit tests to handle the cases of empty usernames/passwords.
Make sure your line coverage is still 100%.