2009-12-25 6 views
6

mi piacerebbe correre unit test per un file di libreria funzioni ...di prova (non classi) con NetBeans e PHPUnit

che è, non ho una classe, è solo un file con le funzioni di supporto in esso ...

per esempio, ho creato un progetto PHP in ~/www/test

e un file ~/www/test/lib/format.php

<?php 

function toUpper($text) { 
    return strtoupper($text); 
} 

function toLower($text) { 
    return strtolower($text); 
} 

function toProper($text) { 
    return toUpper(substr($text, 0, 1)) . toLower(substr($text, 1)); 
} 
?> 
Strumenti

-> creare test PHPUnit mi dà il fol Errore di muggiti:

PHPUnit 3.4.5 by Sebastian Bergmann.

Could not find class "format" in "/home/sas/www/test/lib/format.php".

ora, se il codice I (! a mano) il file ~/www/test/test/lib/FormatTest.php

<?php 
require_once 'PHPUnit/Framework.php'; 
require_once dirname(__FILE__).'/../../lib/format.php'; 

class FormatTest extends PHPUnit_Framework_TestCase { 

    protected function setUp() {} 

    protected function tearDown() {} 

    public function testToProper() { 
    $this->assertEquals(
      'Sebastian', 
      toProper('sebastian') 
    ); 
    } 
} 
?> 

funziona benissimo, posso correre si ...

ma se seleziono file di test da format.php ottengo

Test file for the selected source file was not found

qualche idea?

saludos

sas

ps: Un'altra domanda, c'è un modo per aggiornare prove generate senza doverli eliminare manualmente ???

ps2: utilizzando NetBeans 2.8 dev

+0

Puoi fornire i nomi di file e percorsi per i due file – Yacoby

+0

sicuro, ha appena modificato la domanda per aggiungere quell'informazione ... – opensas

risposta

5

Come avete scritto il vostro banco di prova unità è corretta al 100%. Il problema sta nella convenzione comune e su come PHPUnit e Netbeans fanno affidamento su di essi.

La pratica migliore in questi giorni è scrivere tutto il codice in modo orientato agli oggetti. Quindi, invece di avere un file PHP pieno di funzioni di utilità come hai, si avvolgono queste funzioni in una classe e le hanno come funzioni statiche. Ecco un esempio di utilizzare il codice di cui sopra,

<?php 

class Format 
{ 
    public static function toUpper($text) 
    { 
     return strtoupper($text); 
    } 

    public static function toLower($text) 
    { 
     return strtolower($text); 
    } 

    public static function toProper($text) 
    { 
     return self::toUpper(substr($text, 0, 1)) . self::toLower(substr($text, 1)); 
    } 
} 

Ora usereste le funzioni in questo modo,

Format::toProper('something'); 

PHPUnit, e Netbeans, dipendono da questa filosofia orientato agli oggetti. Quando si tenta di generare automaticamente un caso di test PHPUnit, PHPUnit cerca nel tuo file una classe. Quindi crea un test case basato su questa classe ed è un'API pubblica e la chiama ClassNameTest, dove ClassName è il nome della classe sottoposta a test.

Neatbeans segue anche questa convenzione e sa che ClassNameTest è un caso di test PHPUnit per ClassName, quindi crea un collegamento tra i due nell'IDE.

Quindi, il mio consiglio è di usare sempre le classi dove è possibile. Se si dispone di funzioni di utilità che non dipendono da nulla e vengono utilizzate globalmente, renderle statiche.

Nota a margine: Mi piacerebbe liberarsi delle due funzioni toUpper() e toLower().Non è necessario racchiudere le funzioni PHP integrate quando non ce n'è bisogno. Non è inoltre necessario testarli poiché sono stati accuratamente testati.

Sito nota 2: C'è una specie di costruito in PHP equivalente alla funzione toProper() chiamato ucfirst().

+1

Questi giorni sono lontani. Mi piacerebbe testare il mio php senza OOP. Certo che potrei farlo a mano. Ma preferirei fare affidamento sui benefici di un framework di test. Idee su come scrivere test unitari usando la programmazione procedurale nel 2017? –