PRIVATE->private and PROTECTED->protected updates in Svc/FpySequencer

[m-aleem]

Related Issue(s)	#3446
Has Unit Tests (y/n)	Yes - existing
Documentation Included (y/n)	N/A

---

Change Description

Updates to fprime/Svc/FpySequencer* to change:

• PRIVATE -> private
• PROTECTED -> protected
• Add friend tester helpers, as needed

Rationale

#3446

Testing/Review Recommendations

See questions about Spell Checking CI failure in comment below

Future Work

Additional PRs to be opened for further updates corresponding to #3446

[m-aleem]

CI Spell check is unhappy with the following:

• check-spelling: Svc/FpySequencer/test/ut/FpySequencerTestMain.cpp#L738
  • getstatements is not a recognized word. (unrecognized-spelling)
• check-spelling: Svc/FpySequencer/test/ut/FpySequencerTestMain.cpp#L603
  • getfooter is not a recognized word. (unrecognized-spelling)
• check-spelling: Svc/FpySequencer/test/ut/FpySequencerTestMain.cpp#L564
  • getstatements is not a recognized word. (unrecognized-spelling)

However, these are calls to existing getstatements and getfooter methods (of Fpy::Sequence)

Is there a recommended way to handle this? (I.e. (1) is this OK or (2) should I make a new ticket for this against Fpy::Sequence or (3) incorporate update to the method re-naming as part of this work or (4) something else?)

[LeStarch]

I asked @zimri-leisher to look at this as the original author. For now, this is a reasonable solution and deemed less "ugly" then a friendship statement for each test subclass created by TEST_F.

In the future, all black box testing can use TEST_F but white box testing must add methods to the test for white box access.

[zimri-leisher]

This is an unfortunately large amount of boilerplate... there would be less if we used the FRIEND_TEST macro in gtest. If you guys have deemed that more ugly than this solution, okay fine, but it would require fewer lines of code changed. It would probably be what I would have chosen, but if you've already gone and done this it's fine. I appreciate the large amount of work you've done here, @m-aleem

I wish we weren't being put in this situation, but I suppose it is the right choice to switch to friend classes from private/public redefines.

Now I just feel bad for using TEST_F at all...

[LeStarch]

@zimri-leisher you tried something new, which has very real benefits. Do not feel bad. This is just the normal iteration and learning process.

For example, for purely black-box testing (ports/command and output ports, events, telemetry) TEST_F is an unambiguous win. It just has some minor drawbacks for white-box internal state detection. I personally am adopting TEST_F when my interface is clean enough that black-box testing is sufficient!