Import ipconfig Tests #80
Labels
Good First Issue
Issue does not require detailed knowledge to resolve.
TODO
Changes to code generally transparent to end users.
Projects
I'll prefix: us adding test cases is "new" and we've been doing this as we modify code, so why I made mention of it and why you see there aren't a lot existing.
Generally speaking, what we've been doing is having tests which cover the parts of the parser (this covers probably 4-7 of your list). So they are more unit test oriented. Definitely have "good cases" (they pass) and possibly "bad cases" (they fail). The good cases are basically what the rule is codified to parse. In some cases, the rules have an attached predicate and you can also examine/test the state of the object after a particular parse path. If possible, have a few bad cases which cover instance we explicitly are aware of and want to prevent a refactor from allowing. The parser is pretty good at failing on "bad cases" because of formatting on it's own.
If reasonable, a few interesting whole parser test cases (this covers probably 1-3 of your list) could be added to help a developer understand the general overall structure of the data and some interesting corner cases. However, in many cases it is not reasonable to codify (e.g., a router/switch config) so it's a judgement call. We do run changes through a separate, independent, regression testing so it is covered somewhat there as well.
That said, for parts, probably test:
compartmentHeader
hostData
adapter
servers
since it has it's own test, of the or blockifaceTypeName
dots
servers
ipLine
getIp
ifaceType
Don't worry about testing
token
orignoredLine
as they are fairly simple and we will ultimately, probably, refactor those to a common Parser logic include for consistency across parsers.Originally posted by @marshall-sg in #78 (comment)
The text was updated successfully, but these errors were encountered: