Hey,

1. No problem!

2. You don’t need to change a private field to public just because you use implements. Creating a mock component this way is only needed when you actually need a mock component to do some template testing. By doing implements you get some type safety from the real implementations public methods. If there is a private field, this would simply not be part of the contract, because only the public properties and methods is part of the contract when using implements. For this reason I don’t see why you would need to change a private method to public. Makes sense?
In most of the cases I would do, as you mentioned, mocking using the automatic mock generator, because I don’t need the component decorator.

1. Thanks for sharing
2. Related to mock component via implements like u show. Its bad idea, why?
Cause:
a. U break encupsulation! If u have private field u must chabge it to public, otherwize the tests dosnt work, so u enforce to public the field. This is bad 🙁
b. For each change of your regular conponent u MUST add it to the component code, vut u dont really need to mock it, it just a pure boilerplate. This is just for one conponent think abiut the whole enterprise app. (Its crazy :-))

I think dont put any implement dependency just pure object its better solution. (U have also mock lib that create mock automaticly)