2013-07-01 10 views
14

Mam cechę, która musi zawsze być mieszana z podklasą \PHPUnit_Framework_TestCase. PhpStorm tego nie wie. Czy jest coś, co mogę zrobić, aby PhpStorm automatycznie się uzupełniał i "typecheckował" takie rzeczy jak assertNull wewnątrz cechy?Autouzupełnianie PhpStorm w cechach

<?php 
trait MyTestUtils 
{ 
    public function foo() 
    { 
     $this->assertNu // autocomplete? 
    } 
} 

Najlepszym mogę wymyślić tak daleko jest wprowadzenie następujących w każdej metody:

/** @var \PHPUnit_Framework_TestCase|MyTestUtils $this */ 

Ale to jest powtarzalne i nie rozumie chronione memebers. Czy jest lepsza opcja?

+3

Nie ATM - http://youtrack.jetbrains.com/issue/WI-16368 (lub podobne: http://youtrack.jetbrains.com/issues/WI?q=trait) – LazyOne

+0

Znalazłeś soloution jeszcze? '/ ** @var \ PHPUnit_Framework_TestCase | MyTestUtils $ this */ ' nie działa dla mnie. –

Odpowiedz

4

Twierdzę, że nie jest to poprawny przypadek użycia dla cechy PHP. Twoja cecha, jak napisano, nie jest gwarantowana tylko dla klas rozszerzających \ PHPUnit_Framework_TestCase. To wprowadza bardzo ściśle powiązany kod. Najlepszą praktyką Cechu jest to, że są bardzo luźno powiązani i mają tylko świadomość własnej zawartości.

bym zamiast tego zaleca się albo:

  1. utworzyć podklasę \ PHPUnit_Framework_TestCase że wasze przypadki testowe, które potrzebują tej funkcjonalności mogą przedłużyć
  2. tworzenia niestandardowych klas twierdzenie. Te mogą być wielokrotnie używane do robienia grup niestandardowych asercji.

Obie techniki są opisane tutaj: http://phpunit.de/manual/4.1/en/extending-phpunit.html

Są dwa zalecane najlepsze praktyki, gdzie umieścić metod pomocniczych, takich jak te.

+2

Myślę, że ściśle powiązane cechy są całkowicie uzasadnione w takich scenariuszach. W (głównie) dynamicznym języku musimy (głównie) polegać na dokumentacji, która i tak kieruje użytkownikami naszych abstrakcji. Nadklasy mają problem z trudnością komponowania dowolnie z powodu pojedynczego dziedziczenia.Niestandardowe klasy asercji są odpowiednie, gdy chcesz tworzyć potwierdzenia, ale to tylko jeden specjalny przypadek. – mpartel

6

Poza pomocą bloku dokumentacyjnym php udokumentować $this, tylko inny sposób jestem świadomy, co również sprawia, że ​​prawdopodobnie cecha bardziej „bezpieczny” w każdym razie, jest zdefiniowanie metody abstrakcyjne na samej cechy, np:

trait F { 

    /** 
    * @return string[] 
    */ 
    abstract public function Foo(); 

    /** 
    * @return self 
    */ 
    abstract public function Bar(); 
} 

abstract class Bar { 
    use F; 

    /** 
    * @return bool|string[] 
    */ 
    public function Baz() { 
     if ($this->Bar()) { 
      return $this->Foo(); 
     } 

     return false; 
    } 
} 
+3

Twoja odpowiedź jest niesamowita. W ten sposób deklarujesz silną zależność, która istnieje wewnątrz metod cech. –

+0

To jest niesamowite, teraz klient wyraźnie zna zależności od mojej cechy –

5

UPDATE: od PhpStorm 2016.1.2 (build 145.1616) autocompletion w cechach działa out-of-the-box. Jest wystarczająco inteligentny, aby dowiedzieć się, jakie klasy używają tej cechy, a następnie zapewnić autouzupełnianie. Link do tej kwestii: https://youtrack.jetbrains.com/issue/WI-16368

Wcześniej odpowiedział:

Można użyć:

@method \PHPUnit_Framework_TestCase assertTrue($condition, $message = '') 

... w bloku dokumentacyjnym samej cechy, ale minusem jest to, że trzeba wstawić @method dla każdej metody, która ma być autouzupełniania, co nie jest złe, jeśli używasz normalnej liczby wywołań metod w swojej funkcji. Lub "udokumentuj" tylko te metody, z których najczęściej korzystasz.

+1

Dokumentacja na temat '@ method' docblock https://www.phpdoc.org/docs/latest/references/phpdoc/tags/method.html – fyrye