Mam klasę

[PHP] pobierz, plaintext 
class Foo{
 
    public function a(){
        return $this->b() || $this->c();
    }
 
    protected function b(){
        return time()%2 === 0;
    }
 
    protected function c(){
        return time()%3 === 0;
    }
 
}
[PHP] pobierz, plaintext 

czy możliwe jest przetestowanie a() poprzez zamockowanie b() oraz c()?
Typu:
mockuję b() że zwraca true i wtedy spodziewam się w a() assertTrue()
mockuję c() że zwraca true i wtedy spodziewam się w a() assertTrue()
mockuję b() oraz c() że zwracają false i spodziewam się w a() assertFalse()
mockuję b() oraz c() że zwracają true i spodziewam się w a() assertTrue()

Tak, możesz https://phpunit.de/manual/current/en/test-doubles.html

[PHP] pobierz, plaintext 
class Foo{
 
    public function a(){
        return $this->b() || $this->c();
    }
 
    protected function b(){
        return false;
    }
 
    protected function c(){
        return false;
    }
 
}
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
public function testFoo(){
        $mock = $this->createMock(Foo::class);
        $mock->method('b')->willReturn(true);
        $this->assertTrue($mock->a());
    }
[PHP] pobierz, plaintext 

efekt


natomiast, kiedy b() będzie publiczne, to


//edit
chyba że tak?

[PHP] pobierz, plaintext 
$mock = $this->getMockBuilder(Foo::class)->setMethods(['b'])->getMock();
        $mock->method('b')->willReturn(true);
        $this->assertTrue($mock->a());
[PHP] pobierz, plaintext 

teraz już na zielono

Nie należy mockować testowanej jednostki. W testach jednostkowych mockujesz wszystko poza testowaną jednostką.

Takie podejście uniemożliwia jakąkolwiek refaktoryzacje bez ruszania testów, a wnętrze klasy powinny być pod tym względem elastyczne (czyt. zmiany w implementacji nie powinny powodować wysypywania się testów).
Dodatkowo w takim przypadku Twoje testy są bez sensu, lepiej w ogóle ich nie pisać.

Zobacz tutaj: https://www.schmengler-se.de/en/2011/03/php...-in-unit-tests/

Czy mógłbyś opisać jaki masz konkretny przypadek? Wygląda to trochę tak jakbyś próbował od złej strony podejść do testów. Przede wszystkim jeżeli metody b() i c() są niepubliczne nie powinny być w ogóle ujmowane w testach - są szczegółem implementacyjnym.

Podam przykład. Przypuśćmy, że
a() -> zwraca % postępu jakiejś operacji. Żeby wyliczyć % korzysta z b() -> ile czasu operacja zajmie, c() -> ile czasu uplynelo.
Myślę, że to spoko przykład.
Chcę napisać testy, czy dla konkretnych b() i c() wynik a() będzie taki jak powinien być

To sugeruje, że albo powinieneś mieć - w zależności od stopnia złożoności - prostą funkcję/metodę, która przyjmuje w postaci argumentów te dwie wartości (a nie wyciąga je samodzielnie) albo powinna operować na obiekcie innej klasy, który te dane zwraca - a taki już łatwo podmienić czy to dedykowaną dla testów, "śmieciową" implementacją czy właśnie jakimś mockiem.

Jeżeli powyższe dalej nie jest rozwiązaniem Twojego problemu opisz jak dokładnie wygląda Twoja sytuacja - problemy z testami są najczęściej spowodowane złym zaprojektowaniem systemu.

Pomińmy to, że ta funkcja powinna przyjmować parametry. Przyjmijmy to jak jest, bo odzwierciedla mój problem. Mam helper, który zawiera podobne funkcje jak podane wyżej. Helper jest specyficzny dla danego problemu, dlatego funkcja nie przyjmuje parametrów.W widoku chcę tylko echo $helper->a() i mnie nie obchodzi, co a() robi, ani nie chcę mu dawać parametrów.

I tu dochodzimy do sedna. Testy wspierają dobrą architekturę, której w Twoim rozwiązaniu brak.

Prosta zasada: jak testy są trudne w napisaniu, to coś jest nie tak. Dodatkowo sugeruję stosować TDD, pozbedziesz się takich problemów. Genrealnie z helperami i wszystkim, co statyczne jest problem.