Um.
PER SOLUZIONE JAVA! Non so in che lingua stai programmando!
Ok, ho appena letto "Clean Code" di uno dei Martins, un libro che sostiene che l'idea di refactoring del codice di test per mantenere pulito e leggibile è una buona idea, e in effetti un obiettivo. Quindi l'ambizione di rifattorizzare e mantenere il codice pulito è buona, non un'idea sciocca come pensavo prima.
Ma non è quello che hai chiesto, quindi proviamo a rispondere!
Mi piacerebbe tenere un db dei vostri test - o l'ultimo risultato del test, comunque. Con un po 'di java annotazione, si può fare qualcosa di simile:
@SuperTestingFramerworkCapable
public class MyFancyTest {
@TestEntry
@Test
public testXEqualsYAfterConstructors(){
@TestElement
//create my object X
@TestElement
//create my object Y
@TheTest
AssertTrue(X.equals(Y));
}
}
In ogni caso, si sarebbe anche bisogno di una riflessione e di super classe annotazioni di elaborazione, che avrebbe ispezionare questo codice. Potrebbe essere solo un ulteriore passo in avanti nell'elaborazione: scrivere test, passare attraverso questo super processore e poi, se dovesse superarlo, eseguire i test. E il processore super-sta per utilizzare uno schema MyFancyTest
E per ogni membro che hai nella tua classe, userà una nuova tabella - qui il (solo) tabella sarebbe testXEqualsYAfterConstructors E quel tavolo avrebbe colonne per ogni elemento contrassegnato con l'annotazione @TestElement. E sarebbe anche una colonna per @TheTest suppongo che tu chiameresti solo le colonne TestElement1, TestElement2 ecc. Ecc.
E POI, una volta impostato tutto, salverebbe solo i nomi delle variabili e la riga annotato @ TheTest. Quindi la tabella sarebbe
testXEqualsYAfterConstructors
TestElement1 | TestElement2 | TheTest
SomeObjectType X | SomeObjectType X | AssertTrue(X.equals(Y));
Quindi, se il processore super-va e trova esistono tabelle, allora si può confrontare ciò che è già lì con quello che oggi è nel codice, e può generare un avviso per ogni diversa iscrizione. E puoi creare un nuovo utente - un amministratore - che può ottenere le modifiche e controllarle, crogiolo e ok o no.
E poi si può commercializzare questa soluzione per questo problema, si vende compagnia per 100M e mi danno il 20%
applausi!
giorno lento, ecco il razionale: TUO soluzione utilizza un sacco di overhead in più, più pericolosamente, nel codice di produzione vera e propria. Il tuo codice prodotto non dovrebbe essere legato al tuo codice di test, mai, e certamente non dovrebbe avere variabili casuali che sono specifiche del test in esso. Il prossimo suggerimento che ho con il codice che hai inserito è che il tuo framework non impedisce alle persone di rompere i test. Dopo tutto, si può avere questo:
@Test
public void equalsIfSameObject()
{
Person expected = createPerson();
Person actual = expected;
check(Person.FEATURE_EQUAL_IF_SAME_OBJECT);
boolean isEqual = actual.equals(expected);
assertThat(isEqual).isTrue();
}
Ma se cambio le ultime due righe di codice in qualche "refactoring" di classi di test, allora il vostro quadro sta per segnalare un successo, ma il test non sarà Fai qualcosa. È davvero necessario assicurarsi che venga generato un avviso e che le persone possano guardare alla "differenza".
Quindi, di nuovo, si potrebbe semplicemente voler usare svn o perforce e crogiolo per confrontare e controllare questa roba!
Inoltre, visto che sei appassionato di una nuova idea, ti consigliamo di leggere le annotazioni locali: http: //stackoverflow.com/questions/3285652/how-can-i-create-an-annotation -processor-that-processes-a-local-variabile
Um, quindi potrebbe essere necessario ottenere quello di lui - vedere l'ultimo commento nel link sopra - potrebbe essere necessario anche il suo compilatore java personalizzato.
@Disclaimer Se si crea una nuova società con il codice che segue più o meno quanto sopra, mi riservo il diritto al 20% della società, se e quando si è un valore di oltre 30M, in un momento della mia scelta
Perché si esegue il refactoring del codice di test? Che cosa si ottiene da questo? Non penso di seguire la domanda. Puoi spiegare perché è così importante rifattorizzare il test? Il codice non marcisce spontaneamente. La decomposizione del codice si riferisce a cambiamenti mal pianificati. Quali cambiamenti mal pianificati si verificano nel codice di test? Puoi fornire un esempio concreto? –
Scrivo il test, poi scrivo il codice di produzione, quindi rifatto il codice, sia test che produzione. Potrei anche refactoring il codice di prova più tardi, quando refactoring altro codice di test, al fine di ridurre la ripetizione per esempio. –
"per ridurre la ripetizione"? Perché? Non sono ancora chiaro perché avresti mai toccato il codice di prova. –