DO NOT MERGE: Demonstrate lacking test coverage

[tyll]

To demonstrate that the current test strategy is lacking test coverage,
break the MinMtu data type without breaking the existing test cases.

The second commit introduces Boundary Value Analysis based test cases using doc tests in lack of a better alternative. This is not a proposal for doing the tests exactly as this as I don't have the experience with Rust in how to organize tests best and it might also not be the best tool to use this. This is merely a demonstration about how tests catch problem.

As a note, a boundary value analysis for FailOverMac with [-1, 3] as the bad cases and [0, 2] might have led to using an Enum from the beginning instead of u8, avoiding the later cleanup in 3270863

[cathay4t]

I think boundary test should be done by rust compiler not in this crate. This crate is not responsible for user's fault when using this crate.

[cathay4t]

Whether the data type is correct or not should be determined by reviewer checking linux kernel code on specified netlink attribute.

[tyll]

I think boundary test should be done by rust compiler not in this crate. This crate is not responsible for user's fault when using this crate.

It seems to me that there is a confusion about Boundary Value Analysis as this is not something that a specific component is responsible for but a technique to identify a minimum set of useful test cases. If at all, the rust compile should have test cases identified using the Boundary Value Analysis.

Whether the data type is correct or not should be determined by reviewer checking linux kernel code on specified netlink attribute.

I agree that this should be the source to identify the correct value range for properties. However, ensuring that the code is correct according to the deducted specification from the kernel code is the responsibility of unit tests. See for example: https://www.reddit.com/r/rust/comments/sdag9x/comment/hudzvn0/ - "You write a piece of code in concert with "unit tests" that exercise the code and documents all of its behavior. ". This is currently not happening. https://github.com/rust-netlink/netlink-packet-route#development requests to use unit tests, though.

Also note, that the tests in this PR are not necessarily the best approach to test this as there are other possibilities as well. There could be examples for (de)serialization that use values identified using the Boundary Value Analysis instead of using arbitrary values inside an equivalence partition and the de-serialization test for the boundary values would most likely catch the correct tests as well. However, https://github.com/rust-netlink/netlink-packet-route#development also state that no panic is allowed, so if invalid values lead to a compile error instead of a panic, testing for compile errors is a result of the language design if this is the expected behavior of a crate.

[cathay4t]

Sorry, I failed to understand how to write a unit test for this topic. Please convert this PR into a ready for review PR.

[tyll]

The second commit contains working unit test using the doc test framework.

[cathay4t]

I still don't understand why compiler failure is a unit test of this crate.

I vote no for this PR. Please reach out more maintainers if you think otherwise @ffmancera @little-dude @JohnTitor .

[tyll]

I still don't understand why compiler failure is a unit test of this crate.

The compile failure is the expected behavior of this crate. Maybe it helps writing this as an acceptance criteria:

Given the latest version of netlink-packet-route,
When a developer tries to serialize a negative MTU or a MTU higher than 0x1_0000_0000 with it,
Then the code will not compile.

This test framework is not really great for this because there can be many other reasons why the doc test does not compile which would mask this as well, so it would be great to do this in a better way. For this scenario, the wrong behavior could also be detected by properly de-serializing the boundary values. So having tests that deserialize the bytestreams 0000 and FFFFF would most likely prevent introducing the wrong data type as well. Just realized, that I mentioned this above as well.

I learned, that real bugs have been introduced in the past in this project due to insufficient unit tests:
43a09fb

This would have been caught by having tests to deserialize 0000 and FFFF.

Also the bug from
4f954b5
could have been caught by testing the boundary values for the IPOIB constants: -1, 0, 3, 4.