55d11a5000
> Make the root of the workspace a virtual manifest. It might > be tempting to put the main crate into the root, but that > pollutes the root with src/, requires passing --workspace to > every Cargo command, and adds an exception to an otherwise > consistent structure. > Don’t succumb to the temptation to strip common prefix > from folder names. If each crate is named exactly as the > folder it lives in, navigation and renames become easier. > Cargo.tomls of reverse dependencies mention both the folder > and the crate name, it’s useful when they are exactly the > same. Source: https://matklad.github.io/2021/08/22/large-rust-workspaces.html#Smaller-Tips
1.2 KiB
IronRDP fuzzing
Difference between fuzzing and property testing
ironrdp correctness is validated in various ways. Two of these are fuzzing and property testing.
Both of these methods involve feeding random inputs to the API in order to check if the program is
behaving as expected or not.
However,
-
Fuzzing is well suited for black-box-like testing. Inputs are typically guided by instrumentalizing the code (coverage…) rather than manually informed.
-
Property testing requires the developer to describe the interesting inputs and properties to test.
-
When fuzzing, some properties are tested as well, but those are typically simple (absence of crash, round-trip…).
-
In contrast, property testing is well suited when testing more complex properties.
-
With fuzzing, we are actively trying to show that something is (unexpectedly) broken.
-
With property testing, we are actively trying to show that the properties are holding (as expected).
Targets
pdu_decoding
Feeds random inputs to PDU decoding code.
bitmap_stream
Feeds random inputs to the RDP6 bitmap decoder.
rle_decompression
Feeds random inputs to the interleaved Run-Length Encoding (RLE) bitmap decoder.