[YANGTOOLS-1483] Enrich YangParserTestUtils with String literal YANG methods Created: 03/Feb/23 Updated: 21/Jul/23 Resolved: 12/May/23 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | parser |
| Affects Version/s: | None |
| Fix Version/s: | 11.0.0, 9.0.9, 10.0.9 |
| Type: | New Feature | Priority: | Highest |
| Reporter: | Robert Varga | Assignee: | Matúš Matok |
| Resolution: | Done | Votes: | 0 |
| Labels: | pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
A number of integration tests end up parsing a simple YANG file and make assertions on that. For example, final var it = DefaultBindingGenerator.generateFor( YangParserTestUtils.parseYangResource("/mdsal-810/root-conflict.yang")).iterator(); and the input file is, literally: module root-conflict { // results in RootConflictData
namespace root-conflict;
prefix rc;
container root-conflict-data; // results in RootConflictData as well
}
i.e. a bare-minimum model. Add YangParserTestUtils.parseYang(String... yangContent), which will create the appropriate YangTextSchemaSource (or deeper, as we should derive SourceIdentifier from the content by inspecting the IR). With that we should be able to do the above with: final var it = DefaultBindingGenerator.generateFor(YangParserTestUtils.parseYang(""" module root-conflict { // results in RootConflictData namespace root-conflict; prefix rc; container root-conflict-data; // results in RootConflictData as well }""")).iterator(); This means we do not need to maintain a src/test/resources file and deal with whether it is accessible across modules (as needed for for Class.getResource()). |