[Java/JUnit/MySql]Test per la connessione

[RaouL_BennetH]

Ciao a tutti

Sto provando a cimentarmi un pò con Java e l'utilizzo di Junit. Il mio scopo non è tanto quello di scrivere del codice utile quanto di iniziare a capire qualcosa sul mondo del TDD.

Ho un problema di fondo, e cioè che spesso gli esempi che sono in rete sono un pò lontani dalla mia idea di praticità e concretezza (mio limite) e quindi volevo provare a creare un test che mi permettesse poi di scrivere la classe che dovrebbe gestire la connessione in maniera più pulita.

Sto procedendo in questo modo:

Premetto che sto usando Eclipse come IDE.

Ho creato un nuovo progetto Java. Ho aggiunto i jar relativi a junit e mysql.

Ho inserito un primo file di test che ho fantasiosamente chiamato ConnectionTest. Eclipse me lo ha generato così:

package databaseExperiment;

import junit.framework.TestCase;

public class ConnectionTest extends TestCase {

    protected void setUp() throws Exception {
         super.setUp();
    }

    protected void tearDown() throws Exception {
        super.tearDown();
    }
}

E qui ho i primi dubbi:

Con il metodo setUp() potrei provare a vedere se la connessione è attiva? Ma se è così, non devo prima scrivere la mia classe per la connessione al db? E se quindi è così... che vantaggio ottengo usando un test?

Mi sembra chiaro quindi che ancora non ho capito na mazza sui test

Mi date una mano?

Grazie

RaouL.

[banryu79]

Originariamente inviato da RaouL_BennetH

Mi sembra chiaro quindi che ancora non ho capito na mazza sui test

Mi date una mano?

Grazie

RaouL.

E chi meglio dei ragazzi del progetto Diamond può farlo?
Vedrai che le risposte arriveranno a pioggia, se non sono impegnati in qualche sessione di refactoring pesante

P.S.: io non conosco ancora bene JUnit e i test per poterti essere utile

[RaouL_BennetH]

Originariamente inviato da banryu79

E chi meglio dei ragazzi del progetto Diamond può farlo?
Vedrai che le risposte arriveranno a pioggia, se non sono impegnati in qualche sessione di refactoring pesante

P.S.: io non conosco ancora bene JUnit e i test per poterti essere utile

Ma infatti io sto cercando di "documentarmi" da li.... dopo essere stato inizialmente uno degli autori della storia del gioco e di alcuni personaggi..

Per motivi che non sto ad elencare, non ho potuto poi seguire il tutto e quando cercai di riavvicinarmi, il codice si era talmente evoluto che per me che sono alle prime armi è troppo complicato

Per tornare IT, gli esempi che trovo su internet mi spiazzano per un semplice motivo:

Cioè... ho una classe, e quindi scrivo dei test per testare quella classe e quindi "migliorarla" o riprogettarla.... oppure è al contrario? Cioè... non ho la classe... scrivo il test... ma quindi per testare cosa?!?!?

[banryu79]

Originariamente inviato da RaouL_BennetH

Cioè... ho una classe, e quindi scrivo dei test per testare quella classe e quindi "migliorarla" o riprogettarla.... oppure è al contrario? Cioè... non ho la classe... scrivo il test... ma quindi per testare cosa?!?!?

Nel TDD (Test Driven Development, una tecnica della metodologia di sviluppo agile nota come XP, aka eXtreme Programming, se ho capito bene) i test si scrivono prima del codice vero e proprio: servono per fissare i requisiti minimi che il codice che si va a scrivere deve soddisfare (tra l'altro il codice andrebbe implementato scrivendo solo lo stretto neccessario per passare tutti i test, senza aggiungere altro, (YAGNI), questo almeno è quello che ho capito leggendo i threads di Diamond e altra documentazione online).

Immagino che chi scriva i test lo faccia, a sua volta, nell'ottica di soddisfare i requisiti del "customer" per l'implementazione dei "task" che sono stati precedentemente individuati/fissati per quella "storia".

Sempre immaginando, da quello che ho visto, col precedere dell'implementazione del sistema, i test a loro volta vengono modificati dal codice già esistente (rispetto al test stesso) in sede di refactoring e/o viceversa.

In ogni caso, quel che è certo, è che tutto il codice nuovo è, in teoria, test-driven.

Purtroppo però non sono in grado di darti consigli sull'aspetto pratico, e quindi specifico per la tua situazione, mancandomi l'esperienza diretta (ma lol)

Ciao

[lovaz]

Intanto quella classe di test usa junit v3, dovresti poter
scegliere di generarlo per la v4 dal dialog.

Scrivi uno scheletro di classe, con i metodi non implementati,
implementa i test (che falliranno), e poi scrivi il codice che fa passare i test.

setup e tearDown (o i metodi annotati con @Before e @After in v4) vengono
eseguiti prima e dopo ogni test (annotato con @Test in v4)