Devo testar methods privados ou apenas públicos?

Eu li este post sobre como testar methods privados. Eu normalmente não os testo, porque sempre achei mais rápido testar apenas methods públicos que serão chamados de fora do object. Você testa methods privados? Eu deveria sempre testá-los?

   

    Eu não testo methods privados. Um método privado é um detalhe de implementação que deve estar oculto para os usuários da class. Testar methods privados interrompe o encapsulamento.

    Se eu achar que o método privado é enorme ou complexo ou importante o suficiente para requerer seus próprios testes, eu o coloco em outra class e o publico lá ( Method Object ). Então, posso testar facilmente o método anteriormente privado, mas agora público, que agora vive em sua própria class.

    Qual é o propósito de testar?

    A maioria das respostas até agora está dizendo que os methods privados são detalhes de implementação que não importam (ou pelo menos não deveriam) desde que a interface pública esteja bem testada e funcionando. Isso é absolutamente correto se o seu único propósito para testes é garantir que a interface pública funcione .

    Pessoalmente, meu principal uso para testes de código é garantir que futuras alterações no código não causem problemas e ajudar meus esforços de debugging, se o fizerem. Eu acho que testar os methods privados tão completamente quanto a interface pública (se não mais!) Promove esse propósito.

    Considere: Você tem um método público A que chama o método privado B. A e B fazem uso do método C. C é alterado (talvez por você, talvez por um fornecedor), fazendo com que A comece a falhar em seus testes. Não seria útil ter testes para B também, mesmo que seja privado, para que você saiba se o problema está no uso de C, o uso de C de B, ou ambos?

    O teste de methods privados também agrega valor nos casos em que a cobertura de teste da interface pública está incompleta. Embora essa seja uma situação que geralmente queremos evitar, o teste da unidade de eficiência depende dos testes que encontram bugs e dos custos de desenvolvimento e manutenção associados a esses testes. Em alguns casos, os benefícios da cobertura de teste de 100% podem ser considerados insuficientes para justificar os custos desses testes, produzindo lacunas na cobertura de teste da interface pública. Nesses casos, um teste bem direcionado de um método privado pode ser um complemento muito eficaz para a base de código.

    Eu costumo seguir o conselho de Dave Thomas e Andy Hunt em seu livro Pragmatic Unit Testing :

    Em geral, você não quer quebrar nenhum encapsulamento para testar (ou como a mãe costumava dizer, “não exponha seus privates!”). Na maioria das vezes, você deve poder testar uma class exercitando seus methods públicos. Se houver uma funcionalidade significativa que esteja oculta por trás de access privado ou protegido, isso pode ser um sinal de alerta de que há outra turma que está lutando para sair.

    Mas às vezes não consigo me impedir de testar methods privados, porque isso me dá a sensação de que estou construindo um programa completamente robusto.

    Eu meio que me sinto compelido a testar funções privadas, pois estou seguindo mais e mais uma de nossas recomendações mais recentes de QA em nosso projeto:

    Não mais do que 10 em complexidade ciclomática por function.

    Agora, o efeito colateral do cumprimento dessa política é que muitas das minhas funções públicas muito grandes se dividem em funções privadas muito mais focadas e melhor nomeadas.
    A function pública ainda está lá (é claro), mas é essencialmente reduzida a chamadas todas aquelas ‘sub-funções’ privadas.

    Isso é realmente legal, porque o callstack agora é muito mais fácil de ler (em vez de um bug dentro de uma function grande, eu tenho um bug em uma sub-sub-function com o nome das funções anteriores no callstack para me ajudar a entender ‘como cheguei lá’)

    No entanto, agora parece mais fácil testar diretamente essas funções privadas e deixar o teste da grande function pública para algum tipo de teste de ‘integração’ em que um cenário precisa ser tratado.

    Apenas meus 2 centavos.

    Sim, eu testo funções privadas, porque embora elas sejam testadas por seus methods públicos, é bom em TDD (Test Driven Design) testar a menor parte do aplicativo. Mas as funções privadas não estão acessíveis quando você está na sua class de unidade de teste. Veja o que fazemos para testar nossos methods privados.

    Por que temos methods privados?

    Funções privadas existem principalmente em nossa class porque queremos criar código legível em nossos methods públicos. Não queremos que o usuário dessa class chame esses methods diretamente, mas através de nossos methods públicos. Além disso, não queremos alterar o comportamento deles ao estender a class (no caso de proteção), portanto, é uma propriedade privada.

    Quando codificamos, usamos o design orientado a testes (TDD). Isso significa que, às vezes, nos deparamos com uma funcionalidade privada e queremos testar. As funções privadas não são testáveis ​​no phpUnit porque não podemos acessá-las na class Test (elas são privadas).

    Achamos que aqui estão 3 soluções:

    1. Você pode testar seus privates através de seus methods públicos

    Vantagens

    • Testes unitários simples (não são necessários “hacks”)

    Desvantagens

    • Programador precisa entender o método público, enquanto ele só quer testar o método privado
    • Você não está testando a menor parte testável do aplicativo

    2. Se o privado é tão importante, então talvez seja um codesmell para criar uma nova class separada para ele

    Vantagens

    • Você pode refatorar isto para uma nova class, porque se for tão importante, outras classs podem precisar disso também
    • A unidade testável é agora um método público, tão testável

    Desvantagens

    • Você não quer criar uma class se ela não é necessária, e somente usada pela class de onde o método está vindo
    • Perda potencial de desempenho devido à sobrecarga adicionada

    3. Altere o modificador de access para (final) protegido

    Vantagens

    • Você está testando a menor parte testável do aplicativo. Ao usar final protegida, a function não será substituível (assim como uma privada)
    • Sem perda de desempenho
    • Nenhuma sobrecarga extra

    Desvantagens

    • Você está mudando um access privado para protegido, o que significa que é acessível por suas crianças
    • Você ainda precisa de uma class Mock na sua class de teste para usá-la

    Exemplo

     class Detective { public function investigate() {} private function sleepWithSuspect($suspect) {} } Altered version: class Detective { public function investigate() {} final protected function sleepWithSuspect($suspect) {} } In Test class: class Mock_Detective extends Detective { public test_sleepWithSuspect($suspect) { //this is now accessible, but still not overridable! $this->sleepWithSuspect($suspect); } } 

    Portanto, nossa unidade de teste agora pode chamar test_sleepWithSuspect para testar nossa antiga function privada.

    Eu acho que é melhor apenas testar a interface pública de um object. Do ponto de vista do mundo exterior, apenas o comportamento da interface pública é importante e é para isso que os testes da unidade devem ser direcionados.

    Uma vez que você tenha alguns testes de unidade sólidos escritos para um object, não será necessário voltar e alterar esses testes apenas porque a implementação por trás da interface mudou. Nesta situação, você arruinou a consistência do seu teste de unidade.

    Se o método privado é bem definido (ou seja, tem uma function que é testável e não se destina a mudar com o tempo), então sim. Eu testo tudo o que é testável onde faz sentido.

    Por exemplo, uma biblioteca de criptografia pode ocultar o fato de que executa a criptografia de bloco com um método privado que criptografa apenas 8 bytes por vez. Gostaria de escrever um teste de unidade para isso – não é para mudar, mesmo que seja escondido, e se quebrar (devido a melhorias de desempenho futuro, por exemplo), então eu quero saber que é a function privada que quebrou, não apenas que uma das funções públicas quebrou.

    Ele acelera a debugging mais tarde.

    -Adão

    Se o seu método privado não for testado chamando seus methods públicos, o que ele está fazendo? Eu estou falando privado não protegido ou amigo.

    Se você estiver desenvolvendo um teste orientado (TDD), você testará seus methods privados.

    Eu não gosto de testar a funcionalidade privada por alguns motivos. Eles são os seguintes (esses são os principais pontos para o pessoal do TLDR):

    1. Normalmente, quando você é tentado a testar o método privado de uma turma, é um cheiro de design.
    2. Você pode testá-los através da interface pública (que é como você deseja testá-los, porque é assim que o cliente irá chamá-los / usá-los). Você pode obter uma falsa sensação de segurança, vendo a luz verde em todos os testes de aprovação para seus methods privados. É muito melhor / seguro testar casos de borda em suas funções privadas através de sua interface pública.
    3. Você corre o risco de duplicação de teste severo (testes que parecem muito semelhantes) testando methods privados. Isso tem grandes consequências quando os requisitos mudam, pois muitos mais testes do que o necessário serão interrompidos. Ele também pode colocá-lo em uma posição onde é difícil refatorar por causa de sua suíte de testes … o que é a ironia definitiva, porque a suíte de testes está lá para ajudá-lo a reprojetar e refatorar com segurança!

    Vou explicar cada um deles com um exemplo concreto. Acontece que 2) e 3) estão intrinsecamente conectados, então o exemplo deles é semelhante, embora eu os considere razões separadas pelas quais você não deve testar methods privados.

    Há uma vez que eu considero o teste de methods privados como apropriado, mas vou analisá-lo em mais detalhes posteriormente.

    Eu também repasso porque o TDD não é uma desculpa válida para testar methods privados no final.

    Refatorando sua saída de um design ruim

    Um dos mais comuns (anti) padrões que eu vejo é o que Michael Feathers chama de uma aula de “Iceberg” (se você não sabe quem é Michael Feathers, compre / leia o livro “Trabalhando Efetivamente com o Código Legado”. uma pessoa que vale a pena saber se você é um engenheiro / desenvolvedor de software profissional). Existem outros (anti) padrões que causam esse problema, mas este é de longe o mais comum que eu encontrei. As classs “Iceberg” têm um método público e o resto é privado (e é por isso que é tentador testar os methods privados). É chamado de uma class “Iceberg” porque normalmente há um método público solitário aparecendo, mas o resto da funcionalidade está oculto sob a forma de methods privados. Pode parecer algo assim:

    Avaliador de regras

    Por exemplo, você pode querer testar GetNextToken() chamando-o em uma string sucessivamente e vendo que ele retorna o resultado esperado. Uma function como esta garante um teste: esse comportamento não é trivial, especialmente se suas regras de tokenização forem complexas. Vamos fingir que não é tão complexo, e nós só queremos amarrar fichas delimitadas pelo espaço. Então você escreve um teste, talvez seja algo como isto (alguma linguagem código psuedo agnóstico, espero que a idéia seja clara):

     TEST_THAT(RuleEvaluator, canParseSpaceDelimtedTokens) { input_string = "1 2 test bar" re = RuleEvaluator(input_string); ASSERT re.GetNextToken() IS "1"; ASSERT re.GetNextToken() IS "2"; ASSERT re.GetNextToken() IS "test"; ASSERT re.GetNextToken() IS "bar"; ASSERT re.HasMoreTokens() IS FALSE; } 

    Bem, isso realmente parece muito legal. Queremos ter certeza de que manteremos esse comportamento enquanto fazemos alterações. Mas GetNextToken() é uma function privada ! Portanto, não podemos testá-lo assim, porque ele nem mesmo compilará (supondo que estamos usando alguma linguagem que realmente imponha público / privado, ao contrário de algumas linguagens de script como Python). Mas que tal mudar a class RuleEvaluator para seguir o Princípio da Responsabilidade Única (Princípio da Responsabilidade Única)? Por exemplo, parece que temos um analisador, tokenizer e avaliador em uma class. Não seria melhor simplesmente separar essas responsabilidades? Além disso, se você criar uma class Tokenizer , os methods públicos serão HasMoreTokens() e GetNextTokens() . A class RuleEvaluator pode ter um object Tokenizer como membro. Agora, podemos manter o mesmo teste acima, exceto que estamos testando a class Tokenizer vez da class RuleEvaluator .

    Veja como isso pode parecer na UML:

    Avaliador de regras refatorado

    Observe que esse novo design aumenta a modularidade, portanto, você poderia potencialmente reutilizar essas classs em outras partes do sistema (antes, não é possível, methods privados não são reutilizáveis ​​por definição). Esta é a principal vantagem de quebrar o RuleEvaluator, juntamente com maior compreensão / localidade.

    O teste pareceria extremamente semelhante, exceto que, na verdade, ele compilaria dessa vez, já que o método GetNextToken() agora é público na class Tokenizer :

     TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens) { input_string = "1 2 test bar" tokenizer = Tokenizer(input_string); ASSERT tokenizer.GetNextToken() IS "1"; ASSERT tokenizer.GetNextToken() IS "2"; ASSERT tokenizer.GetNextToken() IS "test"; ASSERT tokenizer.GetNextToken() IS "bar"; ASSERT tokenizer.HasMoreTokens() IS FALSE; } 

    Testando componentes privados através de uma interface pública e evitando a duplicação de testes

    Mesmo se você não acha que pode dividir o seu problema em menos componentes modulares (o que você pode 95% do tempo se você apenas tentar fazê-lo), você pode simplesmente testar as funções privadas através de uma interface pública. Muitas vezes os membros privados não valem a pena testar porque serão testados através da interface pública. Muitas vezes o que eu vejo são testes parecidos, mas testam duas funções / methods diferentes. O que acaba acontecendo é que quando os requisitos mudam (e sempre acontecem), agora você tem 2 testes quebrados em vez de 1. E se você realmente testou todos os seus methods privados, você pode ter mais 10 testes quebrados em vez de 1. Em resumo , testar funções privadas (usando FRIEND_TEST ou torná-las públicas ou usando reflection) que poderiam ser testadas por meio de uma interface pública pode causar duplicação de teste . Você realmente não quer isso, porque nada dói mais do que a sua suíte de testes te atrapalhando. É suposto diminuir o tempo de desenvolvimento e diminuir os custos de manutenção! Se você testar methods privados que são testados por meio de uma interface pública, o conjunto de testes pode muito bem fazer o oposto e aumentar ativamente os custos de manutenção e aumentar o tempo de desenvolvimento. Quando você torna uma function privada pública, ou se você usa algo como FRIEND_TEST e / ou reflection, geralmente acabará se arrependendo a longo prazo.

    Considere a seguinte implementação possível da class Tokenizer :

    insira a descrição da imagem aqui

    Digamos que SplitUpByDelimiter() seja responsável por retornar uma matriz, de forma que cada elemento na matriz seja um token. Além disso, vamos apenas dizer que GetNextToken() é simplesmente um iterador sobre esse vetor. Então, seu teste público pode parecer assim:

     TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens) { input_string = "1 2 test bar" tokenizer = Tokenizer(input_string); ASSERT tokenizer.GetNextToken() IS "1"; ASSERT tokenizer.GetNextToken() IS "2"; ASSERT tokenizer.GetNextToken() IS "test"; ASSERT tokenizer.GetNextToken() IS "bar"; ASSERT tokenizer.HasMoreTokens() IS false; } 

    Vamos fingir que temos o que Michael Feather chama de ferramenta tateante . Esta é uma ferramenta que permite tocar as partes íntimas de outras pessoas. Um exemplo é FRIEND_TEST de googletest, ou reflexo se o idioma for compatível.

     TEST_THAT(TokenizerTest, canGenerateSpaceDelimtedTokens) { input_string = "1 2 test bar" tokenizer = Tokenizer(input_string); result_array = tokenizer.SplitUpByDelimiter(" "); ASSERT result.size() IS 4; ASSERT result[0] IS "1"; ASSERT result[1] IS "2"; ASSERT result[2] IS "test"; ASSERT result[3] IS "bar"; } 

    Bem, agora vamos dizer que os requisitos mudam e a tokenização se torna muito mais complexa. Você decide que um delimitador de cadeia simples não será suficiente e precisará de uma class Delimiter para lidar com o trabalho. Naturalmente, você espera que um teste seja interrompido, mas essa dor aumenta quando você testa funções privadas.

    Quando pode testar methods privados ser apropriado?

    Não há “tamanho único” no software. Às vezes, tudo bem (e realmente ideal) para “quebrar as regras”. Eu defendo fortemente não testar a funcionalidade privada quando você puder. Existem duas situações principais quando penso que está tudo bem:

    1. Eu trabalhei bastante com sistemas legados (e é por isso que eu sou um grande fã do Michael Feathers), e posso dizer com segurança que às vezes é simplesmente mais seguro testar a funcionalidade privada. Pode ser especialmente útil para obter “testes de caracterização” na linha de base.

    2. Você está com pressa e tem que fazer o mais rápido possível por aqui e agora. No longo prazo, você não quer testar methods privados. Mas vou dizer que normalmente leva algum tempo para refatorar as questões de design. E às vezes você tem que enviar em uma semana. Tudo bem: faça o teste rápido e sujo e teste os methods privados usando uma ferramenta tateando, se é isso que você acha que é a maneira mais rápida e confiável de fazer o trabalho. Mas entenda que o que você fez foi suboptimal a longo prazo, e por favor considere voltar a ele (ou, se foi esquecido, mas você o verá mais tarde, conserte-o).

    Existem provavelmente outras situações em que tudo está bem. Se você acha que está tudo bem, e você tem uma boa justificativa, então faça. Ninguém o está impedindo. Apenas esteja ciente dos custos potenciais.

    A desculpa do TDD

    Como um aparte, eu realmente não gosto de pessoas usando TDD como uma desculpa para testar methods privados. Eu pratico o TDD, e eu não acho que o TDD o force a fazer isso. Você pode escrever seu teste (para sua interface pública) primeiro e depois escrever código para satisfazer essa interface. Às vezes eu escrevo um teste para uma interface pública, e vou satisfazê-lo escrevendo um ou dois methods privados menores também (mas não testo os methods privados diretamente, mas sei que eles funcionam ou meu teste público estaria falhando ). Se eu precisar testar casos de borda desse método privado, gravarei um monte de testes que irão atingi-los através da minha interface pública. Se você não consegue descobrir como acertar os casos de borda, este é um sinal forte que você precisa refatorar em pequenos componentes, cada um com seus próprios methods públicos. É um sinal de que suas funções particulares estão fazendo muito e fora do escopo da aula .

    Além disso, às vezes acho que escrevo um teste que é muito grande para mastigar no momento, então acho que “eh voltarei a esse teste mais tarde, quando tiver mais de uma API para trabalhar” (eu vou comentar e mantê-lo no fundo da minha mente). Este é o lugar onde um monte de desenvolvedores que eu conheci irá então começar a escrever testes para sua funcionalidade privada, usando o TDD como o bode expiatório. Eles dizem “ah, bem, eu preciso de algum outro teste, mas para escrever esse teste, vou precisar desses methods privados. Portanto, como não posso escrever nenhum código de produção sem escrever um teste, preciso escrever um teste para um método privado. ” Mas o que eles realmente precisam fazer é refatorar em componentes menores e reutilizáveis, em vez de adicionar / testar um monte de methods privados à sua class atual.

    Nota:

    Eu respondi a uma pergunta semelhante sobre o teste de methods privados usando o GoogleTest há pouco tempo. Eu modifiquei principalmente essa resposta para ser mais agnóstico em termos de linguagem aqui.

    PS Aqui está a palestra relevante sobre aulas de iceberg e ferramentas tateando por Michael Feathers: https://www.youtube.com/watch?v=4cVZvoFGJTU

    Eu não sou um especialista neste campo, mas o teste de unidade deve testar o comportamento, não a implementação. Métodos privados são estritamente parte da implementação, portanto IMHO não deve ser testado.

    Testamos methods privados por inferência, o que significa que procuramos uma cobertura de teste de class total de pelo menos 95%, mas apenas nossos testes exigem methods públicos ou internos. Para obter a cobertura, precisamos fazer várias chamadas para o público / internos com base nos diferentes cenários que podem ocorrer. Isso torna nossos testes mais intensos em torno da finalidade do código que eles estão testando.

    A resposta de Trumpi ao post que você vinculou é a melhor.

    Testes de unidade, acredito, são para testar methods públicos. Seus methods públicos usam seus methods privados, então indiretamente eles também estão sendo testados.

    Eu estive pensando sobre este assunto por um tempo, especialmente com a tentativa da minha mão no TDD.

    Eu me deparei com dois posts que eu acho que resolver este problema completamente suficiente no caso de TDD.

    1. Testando methods privados, TDD e refatoração orientada a testes
    2. O desenvolvimento orientado por teste não está testando

    Em suma:

    • Ao usar técnicas de desenvolvimento orientadas a testes (design), os methods privados devem surgir apenas durante o processo de refatoração do código já em funcionamento e testado.

    • Pela própria natureza do processo, qualquer funcionalidade de implementação simples extraída de uma function completamente testada será auto-testada (isto é, cobertura de teste indireta).

    Para mim parece claro o suficiente que no início da codificação a maioria dos methods será de funções de nível mais alto, porque eles estão encapsulando / descrevendo o design.

    Portanto, esses methods serão públicos e testá-los será bastante fácil.

    Os methods privados virão mais tarde, uma vez que tudo esteja funcionando bem e estamos considerando a legibilidade e a limpeza .

    Como citado acima, “Se você não testar seus methods privados, como você sabe que eles não vão quebrar?”

    Esta é uma questão importante. Um dos grandes pontos dos testes unitários é saber onde, quando e como algo se quebrou o mais rápido possível. Diminuindo assim uma quantidade significativa de desenvolvimento e esforço de QA. Se tudo o que é testado é o público, então você não tem cobertura honesta e delineamento dos internos da class.

    Eu encontrei uma das melhores maneiras de fazer isso é simplesmente adicionar a referência de teste para o projeto e colocar os testes em uma class paralela aos methods privados. Coloque a lógica de compilation apropriada para que os testes não sejam incluídos no projeto final.

    Então você tem todos os benefícios de ter esses methods testados e você pode encontrar problemas em segundos versus minutos ou horas.

    Então, em resumo, sim, teste de unidade seus methods privados.

    Se você não testar seus methods privados, como você sabe que eles não vão quebrar?

    Você não deveria . Se seus methods privados tiverem complexidade suficiente que deve ser testada, você deverá colocá-los em outra class. Mantenha alta coesão , uma class deve ter apenas um propósito. A interface pública da class deve ser suficiente.

    É obviamente dependente do idioma. No passado, com c ++, declarei que a class de teste é uma class de amigos. Infelizmente, isso exige que seu código de produção conheça a class de teste.

    Eu entendo o ponto de vista em que os methods privados são considerados detalhes de implementações e, portanto, não precisam ser testados. E eu ficaria com essa regra se tivéssemos que desenvolver fora do object apenas. Mas nós, somos algum tipo de desenvolvedores restritos que estão desenvolvendo apenas fora dos objects, chamando apenas seus methods públicos? Ou estamos realmente desenvolvendo esse object? Como não somos obrigados a programar objects externos, provavelmente teremos que chamar esses methods privados para os novos públicos que estamos desenvolvendo. Wouldn’t it be great to know that the private method resist against all odds?

    I know some people could answer that if we are developing another public method into that object then this one should be tested and that’s it (the private method could carry on living without test). But this is also true for any public methods of an object: when developing a web app, all the public methods of an object are called from controllers methods and hence could be considered as implementation details for controllers.

    So why are we unit testing objects? Because it is really difficult, not to say impossible to be sure that we are testing the controllers’ methods with the appropriate input which will trigger all the branches of the underlying code. In other words, the higher we are in the stack, the more difficult it is to test all the behaviour. And so is the same for private methods.

    To me the frontier between private and public methods is a psychologic criteria when it comes to tests. Criteria which matters more to me are:

    • is the method called more than once from different places?
    • is the method sophisticated enough to require tests?

    If we test to ensure the correctness of the logic, and a private method is carrying a logic, we should test it. Isn’t it? So why are we going to skip that?

    Writing tests based on the visibility of methods is completely irrelevant idea.

    If I find that the private method is huge or complex or important enough to require its own tests, I just put it in another class and make it public there (Method Object). Then I can easily test the previously private but now public method that now lives on its own class.

    If the method is significant enough/complex enough , I’ll usually make it “protected” and test it. Some methods will be left private and tested implicitly as part of unit tests for the public/protected methods.

    Absolutely YES. That is the point of Unit testing, you test Units. Private method is a Unit. Without testing private methods TDD (Test Driven Development) would be impossible,

    I see many people are in the same line of thinking: test at the public level. but isn’t that what our QA team does? They test input and expected output. If as developers we only test the public methods then we are simply redoing QA’s job and not adding any value by “unit testing”.

    The answer to “Should I test private methods?” is “…….sometimes”. Typically you should be testing against the interface of your classs.

    • One of the reasons is because you do not need double coverage for a feature.
    • Another reason is that if you change private methods, you will have to update each test for them, even if the interface of your object hasn’t changed at all.

    Aqui está um exemplo:

     class Thing def some_string one + two end private def one 'aaaa' end def two 'bbbb' end end class RefactoredThing def some_string one + one_a + two + two_b end private def one 'aa' end def one_a 'aa' end def two 'bb' end def two_b 'bb' end end 

    In RefactoredThing you now have 5 tests, 2 of which you had to update for refactoring, but your object’s functionality really hasn’t changed. So let’s say that things are more complex than that and you have some method that defines the order of the output such as:

     def some_string_positioner if some case elsif other case elsif other case elsif other case else one more case end end 

    This shouldn’t be run by an outside user, but your encapsulating class may be to heavy to run that much logic through it over and over again. In this case maybe you would rather extract this into a seperate class, give that class an interface and test against it.

    And finally, let’s say that your main object is super heavy, and the method is quite small and you really need to ensure that the output is correct. You are thinking, “I have to test this private method!”. Have you that maybe you can make your object lighter by passing in some of the heavy work as an initialization parameter? Then you can pass something lighter in and test against that.

    No You shouldn’t test the Private Methods why? and moreover the popular mocking framework such as Mockito doesn’t provide support for testing private methods.