Ou pode piorar o código. Seguir receitas de bolo, sempre pode criar problemas. Saber o que está fazendo por completo é o coreto e tende a dar melhores resultados.

Um exemplo que vejo muito é a dificuldade que criam em sistemas na parte que realmente fará algo de valor no sistema para facilitar os testes, ou seja, sujam o código, em geral por falta de domínio de todo o processo, de pensar como um engenheiro que cria uma solução sem estragar nada, e em alguns casos deficiências da tecnologia escolhida, o que já é um erro de engenharia que deverá ser compensado com complexidade ou aceitar a falha.

O que foi pensado acima parece uma aberração no sentido que acabei de falar.

Eu não domino Java, mas ser protected faz o método ser acessível no mesmo pacote? Não é só acessível em classes que herdam desta?

(depois me informaram que deixa acessível ao pacote, o que é algo bem estranho e usar uma misfeature da linguagem é pior ainda, ou seja, nem Java sabe OO e fere um dos pilares)

Eu não afirmo que "você" sabe OOP. Eu programo no paradigma há mais de 40 anos, só recentemente eu percebi como OOP realmente é e agora acho que entendo razoavelmente, mesmo assim tem falhas. O fato da maioria das pessoas acharem que sabe e eu vejo quando elas fazem ou falam sobre oi assunto eu sei que não sabem, é um indicativo que está longe da pessoa aprender OOP corretamente, provavelmente nunca acontecerá, porque eu sempre falo, quando você treina o erro é ele que fará para sempre.

Não se deve testar métodos privados, a não ser que tenha um motivo muito forte para isto, deve apensar ter um bom nível de cobertura testando os públicos, se fizer isso certo, os privados será colocados à prova.

Eu duvido que corner case é o termo aplicável no que foi definido.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).