Support for broadcoms multifunctional devices #231
Conversation
Broadcom multifunctional devices use private flags which can be used for distinguishing device capabilities.
to ease further splitting into separate method
Deleted the real-world data because they are huge. Reusing probe_netcard_factory (from commit befef4d, to be merged), to have minimal stubs.
Conflicts: package/yast2-network.changes package/yast2-network.spec test/Makefile.am
Definitely not. Note that the factory code is already shared by 2 tests, and instead of changing the factory to support As for the original 500-line data
The minimal factory approach makes it explicit what each test case needs. |
|
"Minimal stubbing" can be minimal in different ways: minimum code in test to stub it (your version), or minimum number of calls stubbed. I think the latter also has value, especially if it is easy to achieve. But that is a minor point for me. |
|
When I need to use the factory in another test I'll most probably need to use different attributes. So, I'll need to touch this code or use another factory. I did it "my way" bcs I can add device description e.g. obtained from customer easily and all tests would easily use it with no touching. The helper was not about an algorithm but a sort of database which should be filled by data to cover various edge cases which might come. So I definitely have a different approach than you. I wanted to create large read-only data base e.g. filled by real cases to be used as data input, you want it minimal and add special attributes as needed. I've no more comments to the code. |
| # card_ok = Arch::is_xenU () || Arch::ppc(); | ||
| else | ||
| Ops.set(one, "drivers", drivers) | ||
| if drivers == [] |
Just make the factory parametrized, like here: https://github.com/yast/yast-registration/blob/master/test/factories.rb#L4 There I can ask the factory for a generic product, or I can override specific attributes to create product I need in specific test. |
|
Note:
|
then I'd need to use more than 20 parameters. What I mean is that there are plenty of devices, many vendors and lot of state information present in one device description. And there are already an edge cases in the code depending on arch, device type and so on. If the factory only changes device name, mac address and device description it simply is not enough in my POV |
|
We'll see which approach is more suitable as we add more tests and fixtures. This may be resurrected or not. |
Supersedes #227.
I have shown what I think is a better test,
and merged with master to be mergeable,