[objc] Value of unit testing objcgenerator-helpers.cs's GetSignatures and by extension NameGenerator?

[VincentDondain]

I would like someone to enlighten me on the benefits / non benefits of unit testing GetSignatures and NameGenerator.

I know that the current way to test the generated code is to add a bunch of managed code that's supposed to cover all the corner cases and assert it works in objective-c using XCTest.

Meaning that the simple way the objective-c code compiles is fine.

However having extra tests in objcgen would IMHO bring the following advantages:

1. Help debugging the objective-c generator. Maybe there's a way to debug that code other than doing Debug Test in the Unit Test pad with generator.sln open but I don't know it.
2. Enforce formatting rules:
   • Capitalization.
   • No space between type declaration and argument, https://github.com/mono/Embeddinator-4000/issues/196.
   • Space before or after pointer char '*'.
3. Verify our NameGenerator logic:
   • "Avoid one- and two-letter names for arguments", https://github.com/mono/Embeddinator-4000/issues/195. For instance we don't assert that we're indeed avoiding 2 letters arguments since the XCTest don't verify the signature but if the generated code works.

Does that make sense? Is there even more value in testing this?

[spouliot]

Value? yes, it's not a boolean so there's always value :-)

This is not a case where tons of tests are likely to give tons more value. OTOH it's cheap to test and what's not tested generally does not work (for very long). So having a few tests covering the rules and corner cases seems a very good idea. You'll be quickly hit by the law of diminishing returns if you try to add more.

1. You can debug the generator using the generator.sln, just give arguments to the objcgen project.

2. Yes, but it's mostly for regressions (since you'll be supplying the input);

3. Yes, it better be tested (again that will be against known values);

Now if the question was not about unit testing then my answer would likely be different, e.g. writing an ObjC parser to ensure we generated good code against any assembly input.