In TDD dovrei scrivere prima Test o Interface prima?

La tua prima violazione ("Il codice che viene scritto per l'interfaccia non è guidato dal test.") non è valido. Usiamo un esempio banale. Supponiamo che tu stia scrivendo una classe di calcolatrice e stai scrivendo un'operazione di aggiunta. Quale test potresti scrivere?

public class CalculatorTest {
    @Test
    public void testAddTwoIntegers() {
        Calculator calc = new Calculator();
        int result = calc.add(2, 2)
        Assert.assertEquals(4, result);
    }
}

Il test ha appena definito l'interfaccia. È il metodo add , vedi? add prende due argomenti e restituisce la loro somma. In seguito potresti determinare che hai bisogno di più calcolatrici ed estrai un'interfaccia Java (in questo caso) in quel momento. I tuoi test non dovrebbero cambiare, dal momento che hai testato l'interfaccia pubblica di quella classe.

A un livello più teorico, i test sono le specifiche eseguibili per un sistema. Le interfacce verso un sistema dovrebbero essere guidate dagli utenti di quel sistema, e i test sono il primo metodo per definire le interazioni.

Non penso che sia possibile separare la progettazione dell'interfaccia dalla progettazione del test. Definire le interazioni e progettare i test per loro sono la stessa operazione mentale - quando invio queste informazioni in un'interfaccia, aspetto un determinato risultato. Quando c'è qualcosa che non va nel mio input, mi aspetto questo errore. Puoi fare questo lavoro di progettazione su carta e poi scrivere i tuoi test, oppure puoi farlo nello stesso momento - non ha molta importanza.

Che cosa stiamo facendo quando scriviamo un interface ? Stiamo scrivendo il codice o stiamo progettando?

Non sono un fan della nozione di Test Driven Design, ma I love Test Driven Sviluppo . Personalmente, ho ottenuto i miei risultati migliori quando ho progettato la classe in anticipo progettando l'interfaccia prima di scrivere un test. Non considero l'interfaccia come codice. L'interfaccia è un progetto che implementerò utilizzando TDD. È probabile che cambi un'evoluzione mentre lavoro, ma è la mia tabella di marcia (insieme alla mia lista di test).

Mi fermerò prima che inizi a sbraitare, ma spero che sia un modo utile per pensarci.

In TDD should I have to write Test first or Interface first?

Tutto dipende da quanto ortodossi / religiosi vuoi fare TDD .

I am learning TDD

Dal momento che stai imparando, dovresti sperimentare per ottenere un flusso di lavoro personale, che funzioni per te.

1. Se vuoi farlo secondo i libri , scrivi prima un test, che ovviamente fallirà, perché stai iniziando senza alcun codice. Quindi scrivi del codice per far passare il test. Se ciò è fatto, sei libero di refactoring il codice esistente, dal momento che hai un test che fornisce una sorta di rete di sicurezza per i refactoring. Decidere di usare un'interfaccia è una sorta di refactoring.

2. Oltre a TDD o no: la domanda, se utilizzare un'interfaccia o meno non è interessante in primo luogo. Ovviamente, se sei sicuro, hai un comportamento diverso da diffondere tra diversi oggetti, ha senso pensare di usare un'interfaccia: ad esempio, se hai un qualche tipo di output per destinazioni diverse, ha senso implementarlo tramite un'interfaccia Writer e hanno classi diverse per l'output ( FileWriter , Stampante ecc.). Anche se è un detto comune scrivere su un'interfaccia , ma ciò non significa: utilizzare un'interfaccia per tutto . A volte è un livello di riferimento indiretto a molto. Btw. lo stesso vale per i servizi. Ma questo è un argomento diverso.

3. D'altra parte, potresti sviluppare test driven in un altro modo: progetta il tuo codice per verificabilità. Il che significa che scrivi codice, che è facile da testare, anche se scrivi in seguito . Non importa se si scrivono le prove prima o dopo, purché si effettui comunque la prova.

TDD o BDD significherebbe prima eseguire le interfacce di dominio e poi scrivere test contro di loro tramite la mia interpretazione. l'implementazione di un'interfaccia ha un comportamento previsto.

è ancora testato prima del codice perché un'interfaccia non contiene una logica verificabile, è la struttura su cui scrivi un test.

Lo farei come segue

1. Scrivi il comportamento semi-formale (dato: quando: poi :)

2. Scrivi l'interfaccia (al metodo di incapsulamento del comportamento degli host)

3. Scrivi il test identifica (inserisci il dato, chiama il quando, prova il poi)

4. Scrivi / modifica il calcestruzzo (classe che implementa l'interfaccia) per superare il test

Non scrivere mai test prima di aver progettato le interfacce. Quando stai pensando a quali tipi di test scrivere (test design) non dovresti anche progettare contemporaneamente (architettare) la tua applicazione. Non pensare a due cose allo stesso tempo. Hai sentito parlare di separazione delle preoccupazioni? Si applica non solo alla struttura fisica del tuo codice ma anche al tuo modo di pensare.

Decidi come deve essere progettata la tua prima applicazione. Ciò significa che progettate le vostre interfacce e le relazioni tra queste interfacce. Finché non lo hai fatto, non dovresti iniziare a pensare ai test. Una volta che sai quali sono le tue interfacce, puoi prima crearle e poi scrivere test su di loro o scrivere prima i test e poi crearli. In quest'ultimo caso ovviamente non sarai in grado di compilare i test. Non vedo alcun danno né alcuna violazione della filosofia TDD nella creazione delle interfacce prima dei test.

Va bene scrivere l'interfaccia / codice / test contemporaneamente purché la loro incorporazione nel progetto sia atomica.

A meno che il tuo capo non sia religioso riguardo a TDD, nel qual caso probabilmente devi scrivere un'interfaccia vuota - > test - > codice minimale (stepless point) - > più test - > codice più inutile - > più test - > finalmente scrivi il codice reale - > fatto.