Annotazioni.txt

Annotazioni
=========

IDEA PER IL PUNTO 1:
Nel MyTracerClass dobbiamo creare una nuova struttura dati per creare i cammini. Un cammino deve avere un identificativo che secondo me potrebbe essere qualcosa come CLASSE + NOME DEL METODO + NUMERO DELLA SUA ESECUZIONE e come dato per tenere in memoria il cammino si può tenere un'istanza di una list (linkedList, arrayList... ecc) contenente CLASSE/METODO + NUMERO DI BLOCCO.
Esempio:

BaseConstruct/MethodIf-3 --> BaseConstruct/MethodIf@1 || BaseConstruct/MethodIf@2 || BaseConstruct/MethodIf@5 || BaseConstruct/MethodIf@6

dove BaseConstruct/MethodIf-3 vuol dire cammino del MethodIf alla sua terza esecuzione. e Gli altri dopo la @ sono il numero dei blocchi.  
Io pensavo tipo ad un TreeMap o un Hashmap con key l'identificativo e come data una lista.
Altro problema che mi viene in mente. Se i percorsi dovessero risultare troppo grandi per la memoria si può, dopo un tot di dati aggiornare un file di testo con i cammini.  

----

All'inizio del metodo oltre alla chiamata al metodo tracer() ho messo anche una chiamata al metodo recordPath() che ho creato in MyTracerClass. Praticamente questo metodo setta a true una variabile booleana che indica quando deve registrare un percorso e inizializza la lista che dovrà tenere traccia dei blocchi e l'identificativo del percorso.
Da questo momento ogni volta che entra nel tracer gli faccio aggiungere alla lista il blocco chiamato.
Alla fine prendo la lista, ne faccio una copia (perchè penso che altrimenti mi passerebbe un riferimento a quella statica che viene azzerata ogni volta..penso) e inserisco nell'hashmap di percorsi.

-------

Dunque: quello che ora mi metto a fare è una roba di questo genere per il return:
se il metodo ha come return type il void allora uso il codice che ho appena scritto che dovrebbe funzionare
se invece il metodo ha un tipo diverso dal void inserisco la chiamata a quel metodo prima di ogni return in tutto il metodo.

-----

Per risolvere i conflitti del merge se ti interessa è spiegato tutto qua in modo semplice https://help.github.com/articles/resolving-merge-conflicts. 

----

Ho un problema con la rilevazione delle istruzioni. O meglio sul come passarle al tracer.  
Il programma scandisce linea per linea il codice però inserisce la chiamata al tracer all'inizio mentre io ho bisogno di arrivare alla fine del blocco per poter valutare quante istruzioni ci sono.  
Quindi stavo pensando di avere un'altra struttura dati nella classe FileParse in cui memorizzare il nome del blocco e quante istruzioni contiene e passarle alla classe MyTracerClass in un secondo momento. Ti può sembrare sensato?

-----

Allora sì, per la storia dei punti e virgola sarebbero da contare per tutti i blocchi. Ci avevo iniziato a lavorare e se vedi nel codice avevo aggiunto questo metodo findInstructions() che conta i punti e virgola nella linea che gli passi e restituisce l'intero (non conta quelli presenti nelle stringhe) e anche il campo currentIstructionCount. Puoi usare quelli se vuoi.  
Il problema stava, come avevo scritto un po' più in su, nel come passare i dati alla classe my tracer visto che processando riga per riga bisogna attendere la fine del blocco prima di sapere il numero effettivo. Ti cito qual'era il problema se ti sembra senstato
> Ho un problema con la rilevazione delle istruzioni. O meglio sul come passarle al tracer.  
Il programma scandisce linea per linea il codice però inserisce la chiamata al tracer all'inizio mentre io ho bisogno di arrivare alla fine del blocco per poter valutare quante istruzioni ci sono.  
Quindi stavo pensando di avere un'altra struttura dati nella classe FileParse in cui memorizzare il nome del blocco e quante istruzioni contiene e passarle alla classe MyTracerClass in un secondo momento. Ti può sembrare sensato?

------

Io pensavo di effettuare il conteggio con il metodo findInstructions() su ogni linea e incrementare il campo currentIstructionCount e questo lo faccio quando il file viene letto, il problema è quando inserire nella struttura dati(un HashMap per ora) l'identificativo del metodo-blocco e il conteggio delle istruzioni.

------

Per il tuo problema stavo pensando....dunque, visto così ti serve sicuramente un booleano (qualcosa del tipo countInstruction o startCount) che quando è settato a true dice che bisogna contare i punti e virgola, mentre quando è settato a false non bisogna contare. Quindi la chiamata a findInstruction() sarà effettuata solo quando questo campo è true.  
Il problema ora è: quando farlo? Secondo me sarebbe il caso di farlo dopo aver inserito un tracer che non sia il tracer iniziale del metodo (infatti il tracer indica l'inizio del blocco ma bisogna stare attenti a fare in modo di non contare la linea del tracer (con il tracer già aggiunto) altrimenti conterebbe anche i punti e virgola del codice che abbiamo aggiunto noi).  
Settarlo invece a false quando il blocco finisce (qui non saprei si potrebbe vedere qualcosa con le parentesi graffe...al momento non mi viene in mente niente).  
Quindi il procedimento sarebbe: 
> boolean = false --> trovo metodo -> trovo inizio blocco -> inserisco tracer del blocco -> boolean = true -> trovo la fine del blocco -> boolean = false -> inserisco il numero di istruzioni, il metodo corrente con il numero di blocco corrente nella hashmap -> inizializzo a 0 il conteggio delle istruzioni

Ci sarebbe un altro problema però in questo modo. Se c'è un'istruzione fuori da un blocco il metodo non la conterebbe. Per esempio:

```Java
public void method(){ //qua viene inserito il tracer metodo
	System.out.println("Io non vengo contata");  // <--- Questa istruzione non viene contata perchè non è in nessun blocco ma appartiene al metodo 
	if(x== 0){
		//interno del blocco
	}

}
```
------


Sto provando quello che mi hai detto, un problema è che tenendo conto della parentesi graffa chiusa per un blocco succede che mi conta 1 sola istruzione per un blocco di questo tipo anzichè 2:
```Java
if (y == 0) {boolean[] ilMioArrayDiBooleani4 ={y == 0};  MyTracerClass.tracer("src/originalFiles/BaseConstructDue methodIf,void,.",0,6);
			int x = 0;
		}

		x = y > 3 ? 5 : 2;
	 MyTracerClass.endRecordPath("src/originalFiles/BaseConstructDue methodIf,void,.");}
```

Come hai detto tu, per ora le istruzioni prima dei blocchi non vengono contate.
Nel caso eventuale in cui non ce la facessimo a trovare un modo per avere il numero preciso delle istruzioni potremmo sparare un po' a caso, tenendo buono il conteggio molto approssimato.

Se vuoi faccio il commit, dovrei aver lavorato sulla versione tua ultima aggiornata, perché ho rifatto tutto.
Per ora non funziona molto bene perché ha i problemi che ho detto e forse altri.

------

Il passaggio dell'array al metodo tracer funziona sui file di prova. Il passaggio del conteggio elle istruzioni al tracer è più complicato, perchè il termine del conteggio fine effettuato a fine blocco con conseguente inserimento nell'hashMap mentre il metodo viene inserito a inizio blocco. Non saprei quando poter inserire il conteggio delle istruzioni nel metodo.
Magari si potrebbe accedere al numero di istruzioni durante l'esecuzione del metodo tracer, ma ciò richiederebbe salvare esternamente tutti i dati contenuti nell'HashMap.

------

Ho notato un altro problemino (che palle lo so). Quando c'è una classe anonima interna i metodi di quella classe sono salvati nel myTracer con il nome della classe più esterna. Non so se questo potrebbe generare un conflitto o poca chiarezza nel "report" finale.

------

Il numero delle istruzioni interne ad un blocco dovrei inserirlo nell'HashMap countMap della classe MyTracer, giusto? In questo caso posso cambiare l'HashMap da (String,Integer) ad uno con chiave String e con valore una struttura dati che mi permetta di salvare due interi (uno per il numero di volte del blocco eseguito e uno per il numero di istruzioni all'interno del blocco)?
Purtroppo per il problema dei throw, per ora non ti so aiutare.

-----
Sisi si può fare in 2 modi.  
O Crei un'altra mappa apposta per le istruzioni del blocco (così poi ne abbiamo 2, una per il numero delle volte e una per il numero di istruzioni)  
oppure fai come hai detto tu.  
A dirti la verità non ho idea di quale delle due richieda più memoria, se 2 hashmap semplici oppure 1 hashmap più complessa. A questo punto direi di fare come preferisci per me è uguale.  
p.s. cerca di non usare le parentesi angolari '<' e '>' qua perchè mi sa che è un simbolo per nascondere il contenuto.


Per la risoluzione dei throw:  
per sapere se inserirlo o no alla fine mi serve sapere qual'è l'ultima istruzione appartenente al metodo. Allora ho tenuto in una stringa temporanea l'ultima riga di codice appartenente al metodo e a nessun blocco (l'ho calcolato in base al numero di parentesi { spaiate) Se arrivo in fondo al metodo guardo l'ultima riga salvata e calcolo l'ultima istruzione. Se è un throw o un return allora non inserisco l'endOfPath().  

Altro errore di cui mi sono accorto: ASTParser non tiene conto dei metodi dichiarati all'interno di un'istruzione...tipo

```Java
protected void indexNodes(List<Node> nodes, RuleContext ctx) {
		PLSQLParserVisitor plsqlParserVistor = new PLSQLParserVisitorAdapter() {
			@Override
			public Object visit(PLSQLNode node, Object data) {
				return super.visit(node, data);
			}
		};
		LOGGER.exiting(CLASS_NAME, "indexNodes");
}
```
Legge il metodo indexNodes() ma il visit() dentro non lo conta. E' un problema tralasciabile nel senso che non crea conflitto ma alla fine il programma non tiene conto della copertura di quei metodi.  
Lo lascio come un punto da fare ma se ci avanza tempo

-----
Mi sa che forse inserire il numero di istruzioni nella struttura dati del MyTracer prima dell'inserimento della chiamata endRecordPath() non è possibile. Non vorrei dire una cazzata, vediamo se ho capito bene. 
In pratica prima di inserire la chiamata al metodo endRecordPath(), nella classe FileParser, dovrei prendere dall'HashMap il numero di istruzioni di un blocco ed inserirle all'interno dell'HashMap della classe MyTracer.
Il problema è che il metodo tracer viene eseguito dopo aver effettuato il preprocessing e quando esso viene eseguito, nella strttura dati che dovrebbe contenere i numeri di istruzioni inseriti precedente, non c'è più niente.
L'ho spiegato male e probabilmente mi sto sbagliando.
Delle volte, quando dovrei inserire il numero di struzioni nell'HashMap della classe MyTracer incontro delle nullPointer perché cerco il valore di una chiave(metodo-blocco) che non è presente nell'hashMap che contiene il numero di istruzioni appartenente alla classe fileParser.

-----

Sisi ho capito il problema. Hai ragione tu non si può.  
Dobbiamo per forza passare tutto nel preprocessing e non aspettare che venga eseguito.  
Difatti il numero di istruzioni deve essere presente prima dell'esecuzione dei test.  
A questo punto direi o di salvare il numero di istruzioni in qualche variabile e nella chiamata dell'endprocess() passare tutto al nel MyTracerClass (ma è abbastanza incasinato perchè verrebbe un metodo lunghissimo a seconda del numero di blocchi nel metodo)  
Oppure conviene salvare il tutto su un file separato e poi quando è necessario uno va a prenderlo. Tipo il file MetodiTirocinio che fa ASTParser

-----
Ok risolto anche l'ultimo problema...Posso fare il commit o devi committare qualcosa prima?
p.s. ho visto la stampa su file. Secondo me ti conviene metterla in un formato facilmente parsabile tipo invece del  
```blocco()  Numero di istruzioni:  10```  
si potrebbe mettere al posto di "numero di istruzioni:" un carattere speciale a scelta così quando facciamo il parsing ci basterà splittare con quel carattere  
```blocco()#10 ```  
o roba simile.

-------
Ho dato un ordine di priorità alla todoList. Se trovi qualcosa di incongruente cambia/aggiungi pure.  
Ora mi stavo dedicando un po' all'interfaccia grafica faccio il commit di quel poco che ho fatto così evitiamo commit troppo grossi che sfalsano tutto.
C'è una cosa che bisogna fare assolutamente (finito di mangiare provo a guardare su internet se c'è qualcosa di già fatto) se hai già idea di come fare o lo sai scrivi pure.
In pratica bisogna riuscire dal path del file a ottenere la nomenclatura della classe (in pratica bisogna riuscire a tirare fuori il risultato del metodo getClass() di un oggetto avendo solo il path del file del file sorgente di quell'oggetto). Server assolutamente per far partire i test (e secondariamente per risolvere un problemino con la nomenclatura dei file per pmd).  
In parole povere se ho ad esempio questo percorso: 

```C:\Users\Marco\Desktop\pmd-src-5.1.1\src\main\java\net\sourceforge\pmd\lang\java\typeresolution\rules\imports\UnusedImports.java ```

con questo path:

```/pmd/src/main/java/net/sourceforge/pmd/lang/java/typeresolution/rules/imports/UnusedImports.java ```

dovrei ottenere una stringa di questo tipo (l'ho presa dal metodo getClass()) 

```net.sourceforge.pmd.lang.java.typeresolution.rules.imports.UnusedImports ```

che corrisponde all'identificatore univoco della classe.
Parsare il path e sostutire i punti non penso sia un'opzione perchè il percorso/path varia ogni volta in base ai package e a dove è messo.

-----

Per ora non ho trovato niente, se il parsing non è fattibile e non c'è nessun metodo che fa questa cosa non saprei come fare. Forse bisogna cercare qualche altro metodo per far partire le classi di test per Junit.

------
Io forse ho trovato qualcosa. Devo testare per vedere se funziona. E ti faccio sapere.  
Se riesci a trovare un altro modo più facile per far andare i test di junit ben venga. Neanche a me piace tanto come funziona JunitCore

------
Mah no mi servirebbe una classe che non so dove trovare (il riferimento che stavo guardando è questo:  
http://stackoverflow.com/questions/3845823/getting-list-of-fully-qualified-names-from-a-simple-name)  
La classe sarebbe ClasspathPackageProvider che non ho capito dove pescarla. 
Tuttavia ho letto che il fully qualified name della classe, cioè quello che ci serve, è comunque sempre deducibile dal path. Il vero problema rimane quindi come capire quali sono package e quali sono cartelle nel path della classe. Una volta capito quello il gioco è fatto e basterebbe parsare semplicemente il path con solo i package.  
O in alternativa si potrebbe trovare qualcosa di alternativo a JunitCore ma non saprei dove sbattere la testa per questo.

--------
In pratica bisogna riuscire dal path del file a ottenere la nomenclatura della classe (in pratica bisogna riuscire a tirare fuori il risultato del metodo getClass() di un oggetto avendo solo il path del file del file sorgente di quell'oggetto). Server assolutamente per far partire i test (e secondariamente per risolvere un problemino con la nomenclatura dei file per pmd).  
In parole povere se ho ad esempio questo percorso: 

```C:\Users\Marco\Desktop\pmd-src-5.1.1\src\main\java\net\sourceforge\pmd\lang\java\typeresolution\rules\imports\UnusedImports.java ```

con questo path:

```/pmd/src/main/java/net/sourceforge/pmd/lang/java/typeresolution/rules/imports/UnusedImports.java ```

dovrei ottenere una stringa di questo tipo (l'ho presa dal metodo getClass()) 

```net.sourceforge.pmd.lang.java.typeresolution.rules.imports.UnusedImports ```

che corrisponde all'identificatore univoco della classe.
Parsare il path e sostutire i punti non penso sia un'opzione perchè il percorso/path varia ogni volta in base ai package e a dove è messo.

-----

Per ora non ho trovato niente, se il parsing non è fattibile e non c'è nessun metodo che fa questa cosa non saprei come fare. Forse bisogna cercare qualche altro metodo per far partire le classi di test per Junit.

------
Io forse ho trovato qualcosa. Devo testare per vedere se funziona. E ti faccio sapere.  
Se riesci a trovare un altro modo più facile per far andare i test di junit ben venga. Neanche a me piace tanto come funziona JunitCore

------
Mah no mi servirebbe una classe che non so dove trovare (il riferimento che stavo guardando è questo:  
http://stackoverflow.com/questions/3845823/getting-list-of-fully-qualified-names-from-a-simple-name)  
La classe sarebbe ClasspathPackageProvider che non ho capito dove pescarla. 
Tuttavia ho letto che il fully qualified name della classe, cioè quello che ci serve, è comunque sempre deducibile dal path. Il vero problema rimane quindi come capire quali sono package e quali sono cartelle nel path della classe. Una volta capito quello il gioco è fatto e basterebbe parsare semplicemente il path con solo i package.  
O in alternativa si potrebbe trovare qualcosa di alternativo a JunitCore ma non saprei dove sbattere la testa per questo.

Per chiarezza ho tolto tutta la parte iniziale del readMe ma siccome potrebbe essere comunque del materiale utile (magari possiamo attingere qualcosa o qualche fonte per la tesi) ho salvato tutto e l'ho messo in un file chiamato Annotazioni.txt all'interno del progetto. Se ti serve prendere/rivedere qualcosa è salvato tutto lì.

Idea! E' un po' brutto ma mi sembra l'unica soluzione al momento:  
ho guardato qua e là ma mi sembra che JunitCore sia l'unica classe in grado di far andare i test di Junit...comunque l'idea è di far specificare all'utente dove si trova il package generale dei source e poi della classe test.  
Quindi si ha così la prima parte di ogni path che andrà rimossa. Nella restante parte si sostituiscono i / con i . e il gioco è fatto. Il problema è che l'utente deve fare un po' più di cose tutto qui.
Sto cambiando l'interfaccia per permettere questo.

------

Ho inserito nella classe MyTracer la struttura dato che contiene il numero di istruzioni e ora ogni volta che viene eseguito il metodo tracer, viene anche stampato il numero di istruzioni nel blocco. Per ora se il metodo tracer viene eseguito con parametro metodo-idBlocco non presente nella struttura dati, il numero di istruzioni l'ho messo convenzionalmente a -1. Magari, se ci servirà, più avanti si potranno effettuare calcoli statistici sul numero di istruzioni anche sulla base del metodo (al posto del valore convenzionale -1).
Io ho modificato solo La classe MyTracerClass, quando vuoi dimmi se posso effettuare il commit, altrimenti lo farò dopo il tuo aggiornamento.

------

Ok. Nono committa pure..Io non sto lavorando sul MyTracerClass quindi non dovrebbero neanche esserci conflitti di merge. 

Problemi con il classLoader. Ora i nomi riesco a prenderli giusti ma sembra che bisogna avere un classLoader che carichi le classi dei test altrimenti JunitCore non li fa partire ..ci sto lavorando (poi però bisognerà specificare anche nel parenthesysAdder un nuovo path perchè tutti i nomi non saranno più packageesterno/packageinterno/classe ma sarà tutto l'elenco dei package: pack1.pack2.pack3.classe).
Vedo cosa si può fare per il ClassLoader

Ho trovato una classe che si chiama URLClassLoader in cui si può specificare un URL dove il nuovo loader andrà a pescare jar e directory però non funziona e non capisco perchè. Qualsiasi cosa gli passo nel costruttore lui con il metodo getResource() mi fa vedere che va sempre nella cartella bin di eclipse del progetto corrente (cioè quello del tirocinio) e ovviamente non trova le classi di test di PMD. Non so che fare. Non capisco se sbaglio io o se URLClassLoader è la classe sbagliata per lo scopo. Ora continuo a provare qualcosa. Se rimango senza idee faccio una domanda su StackOverflow perchè non so come andare avanti.

------
Sto testando tutto anche su Junit e sembra che funzioni, il numero di istruzioni mi sembra abbastanza impreciso, però almeno non dà probremi.

------
Credo di stare diventando matto.  
Scusami ti faccio una domanda banalissima da novellino java perchè sembra che il mio problema sia qui.  
Ho un file .java, una classe semplicissima che stampa il nome della classe. L'ho messa in questa directory:
```C:/java/test/sec/ ``` e l'ho chiamata **Test.java**. Ora, tramite linea di comando vado in quella directory e faccio ```javac Test.java ``` e mi compila il file. Mi crea il **Test.class**. Poi quando lo dovevo eseguire ho fatto ```java Test ``` sempre da dentro la directory e mi dice che non trova il file.  
Allora mi sposto su di una directory e provo ```java sec/Test ``` essendo in ```C:/java/test/ ``` e ancora niente e faccio così fino in ad arrivare in C ma niente. Come diavolo la eseguo da riga di comando?
Questa è la classe:  

``` Java
package test.sec; 
public class Test {

	public Test() { 
	} 
 
	public static void main(String[] args){
		System.out.println(new Test().getClass());
	}
}
```
E' un problema del mio pc o sono io che sono rimbambito?

------
Dopo un po' di tempo ci sono riuscito in questo modo(ho usato le tue stesse impostazioni di directory e il file che mi hai postato):
- ho compilato la classe come hai fatto tu.
- Poi sono andato nella directory java con il comando(cd \java) e qui ho eseguito il comando  ```java test.sec.Test ``` quindi mi ha stampato "class test.sec.Test".

----------
Ok credo proprio di avere qualche problema col pc perchè (l'avevo già fatto) ho comunque riprovato come hai detto tu e mi dice che non mi trova il file specificato.
Quindi devo risolvere sto problema..proverò a reinstallare java (dio mi salvi) e rifare perchè ho un problema quasi uguale con i test di Junit...ho il nome, ho il ClassLoader nella cartella dei .class e mi dice che non me li trova quindi penso sia un problema del mio pc. Ora reinstallo java e ti faccio sapere.

-----

Non riesco proprio a capire. Ho reinstallato java e ho riprovato ma nulla. Poi mi è venuto in mente del CLASSPATH. L'ho settato che puntava su quella cartella ed è andato tutto ok sono riuscito a stampare il class test.sec.Test.  
Così ho messo fatto puntare il classpath alle classi di test di pmd e facendo partire tutto mi dava o delle CalssNotFoundException o NoClassDefFoundException. Non riesco a farlo partire. Domani mi sa che faccio domanda su stackOverflow. Se vuoi poi posso fare il commit se ci vuoi dare un'occhiata o se vuoi provare a farlo funzionare anche te.Dimmi tu (faccio tutto domani che ora vado a dormire)


Ho fatto la domanda su stackoverflow. Se la vuoi vedere è qui 
http://stackoverflow.com/questions/25845911/obtain-class-istances-in-a-directory-from-urlclassloader

-----


Se vuoi fai pure il commit così lo vedo anch'io.
Intanto qualcuno risponde così su stackoverflow:
Seeems I'm having some problem: Which problem? –  JB Nizet 4 mins ago

-----
Praticamente ora tutti i file vengono salvati con il loro FQN (Fully qualified name) ma per fare questo ho bisogno di fare come ti avevo detto: specificare il path originale del package più esterno così da poterlo sottrarre al path completo del file.  
Quindi nel ParenthesysAdder va specificato nel main  
```String rootPath = "C:/Users/Marco/Desktop/pmd-src-5.1.1/src/main/java"; ```  
Questo è praticamente dove iniziano i miei package di pmd. Questo path verrò poi chiesto di essere specificato dall'utente nell'interfaccia (se non capisci qualcosa nell'interfaccia prova a vedere il tooltip sulle Label).
Se hai qualche problema fammi sapere.

-----

Testando mi sembra di avere il tuo stesso problema ClassNotFoundException. Non so se ho capito tutti percorsi esatti da inserire nei campi dell'interfaccia (te li scrivo un attimo per vedere se ho capito).
- Source folder: dove sono presenti i file sorgente es: C:\Users\Jacopo\Desktop\junit-master\src
- Destination folder: la directory di destinazione della copia.
- Additionals file folder: la directory dove verranno salvati file addizionali.
- Packages folder: la prima cartella contenente packages-. es: C:\Users\Jacopo\Desktop\junit-master\src\main\java

- Test folder: dove si trova la directory contenente i test. es: C:\Users\Jacopo\Desktop\junit-master\src\test
- Compiled test folder: dove si trovano i .class dei file di test. es: C:\Users\Jacopo\Desktop\junit-master\bin\junit\tests

-----

Si esatto... i file addizionali sarebbero quelli tipo MetodiTirocinio.txt o NumeroIstruzioni.txt.  
*Packages folder* è quella fino al primo package. Si per junit è corretta quella perchè i packages iniziano tutti o con org.qualcosa.ecc oppure con junit.qualcosa.ecc
per sapere se è corretto dovresti provare a far partire tutto (non da interfaccia che il preprocessing non lo fa ancora) ma normalmente dal parenthesysAdder. Se i file come metodiTirocinio o NumeroIstruzioni sono corretti (ossia non hanno null al posto del nome del metodo) allora dovrebbe essere corretto.  
Test folder dovrebbe essere sbagliata. Nel mio Junit dovrebbe essere *C:\Users\Marco\Desktop\junit-master\junit-master\src\test\java* perchè tutti i packages iniziano con junit.blablabla o con org.blablabla quindi bisogna includere anche *\java*.  
Compiled test folder dovrebbe essere giusta.  
O almeno, non capisco quest'ultima ho provato con diversi livelli (nel tuo caso sarebbe da provare tipo arrivare fino \junit-master\bin\junit\ e provare poi fare fino \junit-master\bin\ e provare o andare anche più avanti) di path ma non capisco se si trova lì l'errore.  
Prova comunque a cambiare il test folder come ti ho detto. (se guardi il fullname dovrebbe essere corretto. Se non è corretto è sbagliata la "root" dei package: in questo caso quindi la *Test folder*).

-----
Mi hanno risposto su stackoverflow e credo di aver capito il problema. Ora riesco a far partire alcuni test!  
Ci sto lavorando. Il problema è come diceva lui che non trova le classi usate dai test non quelle dei test in sè. Ho aggiornato il Classpath e aggiunto un secondo bin con le classi dei file e riesce a eseguire qualcosa ma da ancora qualche eccezione che ora vedo di risolvere.

----
Boh sto provando...ho risolto un bel po' di problemi con sta cosa ma ora arriva ad un punto e si ferma. Non va avanti e non da eccezioni nè stackOverflowException niente di niente. Si impalla tutto e basta..sto provando a vedere cos'è ma si ferma sempre al solito punto...0 eccezioni mah.  
Vedremo.  
Ho da chiederti una cosa: puoi fare in modo che ogni volta che si fa ripartire tipo il parenthesysadder il file NumeroIstruzioni.txt venga ricreato da 0? Perchè continuandolo ad eseguire aggiunge sempre i dati a quello vecchio che lo fa diventare lunghissimo e con ripetizioni.  
Se non riesci non importa, piuttosto che fare casini meglio averlo così.

----

Cosa potrei fare io ora? Potrei iniziare a vedere come gestire i dati raccolti? Magari possiamo metterci d'accordo sui dati da raccogliere e sulla modalità di raggruppamento dei dati in modo tale da poter incominciare a farci qualcosa.

---------

Allora ti dico quello che al momento sto facendo io:  
prima dovrei risolvere la faccenda dell'esecuzione dei test che si blocca. Devo arrivare a far funzionare tutti i test in modo corretto.  
Fatto questo mi dedico al far partire il preprocessing da interfaccia grafica (che avevo già inziato) e al far fare all'interfaccia una cosuccia che se mi viene dà un bell'effetto. (praticamente siccome per i test è necessario specificare tutti i path delle classi o delle librerie esterne usate volevo far apparire dinamicamente a seconda della scelta dell'utente un numero arbitrario di caselle di testo in cui inserire i path specificati. Poi questi saranno gli argomenti dell'URLClassloader).  
Al momento mi sto dedicando a questo.  
Sì, ci sarebbe da "elaborare" i dati raccolti fino ad adesso. Fin'ora abbiamo: i path di esecuzione, i vari blocchi, il numero di volte che un metodo viene eseguito e il numero di istruzioni per blocco.  
Al momento l'unica cosa che facciamo è farli stampare a video ma bisognerebbe farci qualcos'altro. Per esempio io pensavo di creare un file html in cui i risultati sono formattati in una tabella e suddivisi tipo per classe. (poi questo file si potrà far vedere anche da interfaccia grafica volendo).
Oppure ci sono per l'appunto da fare un po' di calcoli che aveva richiesto il prof. Tipo la storia della casualità, del procedere e tutte le altre cose che ora non mi vengono in mente.
Infine dobbiamo considerare che manca ancora l'ultimo punto (il 5) cioè dobbiamo ancora raccogliere quanta copertura ha una classe di test (questo però va fatto dentro al ciclo for dell'interfaccia. Cioè prima dell'istruzione ```Result result = junit.run(cl);```  andrebbe messo un metodo che dica di iniziare a registrare la copertura e dopo averlo eseguito uno che dica di finire di registrare) Però non mi sembra il caso di iniziare a verificare la copertura dei test se non riusciamo/riesco ancora a farli partire tutti in modo decente.  
Dimmi tu cosa preferisci fare.

Domani vuoi che scriviamo una mail al prof che gli diciamo come stanno andando le cose?  
Altra domanda: tu giovedì vai a vedere le lauree?

---------

Per ora sul file viene scritto quello che veniva stampato a video.
Stavo pensando a come ordinare i dati per classi, i dati vengono stampati a seconda di dove vengono eseguiti i test e per ordinare il file, si potrebbe fare un altro file che viene ordinato ogni volta al momento dell'esecuzione del metodo tracer oltre a quello attuale.  
Altrimenti bisognerebbe analizzare il file con i dati in un'altra esecuzione.
Per i dati che si potrebbe raccogliere sono: 
- quanti metodi e quali metodi vengono eseguiti di una classe, 
- quante istruzioni di un metodo vengono eseguite durante un cammino, 
- quali blocchi e quanti blocchi vengono eseguiti di un metodo  

Poi bisogna ancora analizzare l'array di booleani.
La mail si può scrivere, poi ci sentiamo per metterla giù.
Giovedì penso di non esserci, mi mette un po' ansia vedere le lauree e poi mi fa anche un pochino arrabbiare per come è andata.

------
Ok. Per la mail magari ci sentiamo oggi pomeriggio?  
Ah ok, no anche a me gira un po' per le lauree però era giusto per vedere come ci si comportava. Però non penso di esserci boh vedrò giovedì.  
Sembra che abbia risolto la faccenda del test. In realtà non si impallava tutto ma quando andava ad eseguire una classe particolare dei test di pmd (e ora però mi fanno anche girare un po' i cosiddetti quelli di pmd) per come è scritta questa classe devia tutto l'output in una cartella del progetto che crea e che mi fa un file txt di più di 9 Megabyte. Una volta rimossa quella classe di test tutto funziona. Però non so come gestirla altrimenti. Se dovessi lasciarla questa fa delle robe con questo codice:
```Java 
public class CLITest {
	private static final String TEST_OUPUT_DIRECTORY = "target/cli-tests/";

	// Points toward a folder without any source files, to avoid actually PMD
	// and slowing down tests
	private static final String SOURCE_FOLDER = "src/main/resources";

	/**
	 * @throws java.lang.Exception
	 */
	@BeforeClass
	public static void setUp() throws Exception {
		System.setProperty(PMDCommandLineInterface.NO_EXIT_AFTER_RUN, "true");
		File testOuputDir = new File(TEST_OUPUT_DIRECTORY);
		if (!testOuputDir.exists()) {
			assertTrue("failed to create output directory for test:"
					+ testOuputDir.getAbsolutePath(), testOuputDir.mkdirs());
		}
	}

	private void createTestOutputFile(String filename) {
		try {
			PrintStream out = new PrintStream(new FileOutputStream(filename));
			System.setOut(out);
			System.setErr(out);
		} catch (FileNotFoundException e) {
			fail("Can't create file " + filename + " for test.");
		}
	}
```

Per il momento la tolgo. Ho quasi finito quella cosa che ti dicevo dell'interfaccia. Ora mi manca da far partire il preprocessing da interfaccia con tutti i dati specificati.
Per quanto riguarda quello che hai detto secondo me far partire un'altra esecuzione che scandisca il file finale e lo "riordini" è molto meglio e si può fare facilmente (basta aggiungere uno step all'interfaccia con un pulsante ed è fatta) rispetto al riordinare ogni volta che viene chiamato il tracer che la cosa si farebbe piuttosto pesante penso.  
Altra cosa che mi viene in mente da fare poi in seguito è gestire le situazioni in cui l'utente sbaglia a inserire qualcosa (tipo path scorretti o directory non esistenti) mostrando gli errori e catturando con eccezioni nel codice.  
Però è secondario, prima cerchiamo di ottenere tutto con i dati giusti.

------

Ci ho messo più del previsto (ovviamente problemi su problemi) però ora sembra che funzioni. Spero non incasini tutto ora faccio il commit.

------

Sono riuscito a far andare la copia e il preprocessing.

---------------

Ok ora faccio un elenco dettagliato con cosa bisogna inserire nelle form:

- Source folder: la cartella da copiare. Quella che contiene tutto il progetto/programma. es. *C:\Users\Marco\Desktop\pmd-src-5.1.3\*
- Destination folder: cartella dove verrà ricopiato tutto il progetto/programma. es *C:\Users\Marco\Desktop\nn\*
- Additional file folder: cartella dove verranno salvati i file intermedi come MetodiTirocinio.txt, NumeroIstruzioni.txt (e spero di riuscire a metterci anche tutte le analisi statistiche). es. *C:\Users\Marco\Desktop\files*
- Original package folder: cartella "root" dove iniziano i package (nel progetto originario). es. *C:\Users\Marco\Desktop\files*
- Destination packages folder: come quella sopra solo che del progetto che è stato copiato. es. *C:\Users\Marco\Desktop\nn\src\main\java*
- Test folder: dove sono presenti i sorgenti dei test .java nel progetto copiato (sempre nella cartella più in alto possibile diciamo) es. *C:\Users\Marco\Desktop\nn\src\test\java*
- Compiled test folder: dove sono presenti i .class dei test es *C:\Users\Marco\Desktop\nn\target\test-classes*
- Compiled source code folder: dove sono presenti i .class dei sorgenti es. *C:\Users\Marco\Desktop\nn\target\classes*
- Additional folder or jars: qui premendo sul [+] si aggiungono campi extra dove bisogna inserire eventuali dipendenze da librerie esterne es. *C:\Users\Marco\.m2\repository\org\apache\ant\ant-testutil\1.7.1\ant-testutil-1.7.1.jar*

Ho una domanda: potresti spiegarmi in breve le dipendenze dei percorsi tra MyTracerClass e StatisticsDataOrder? Nel senso: siccome vorrei far mettere tutti i file nuovi che hai aggiunto tipo DatiStatistici.txt o FilePercorsi.txt in una cartella specificata volevo sapere dove dovevo cambiare i path e come interagivano tra loro (tipo: viene letto in questa classe due volte e viene invece scritto in questa con un buffered reader) così poi posso provare a metterli.

------
- Il file DatiStatistici viene scritto nella classe MyTracerClass e viene letto nella classe StatisticsDataOrderer per scrivere i dati in ordine alfabetico nel file DatiStatisticiOrdinati.
- Il file DatiStatisticiOrdinati viene scritto nella classe StatisticsDataOrderer.
- Il file NumeroIstruzioni viene scritto nella classe MyTracerClass e mostra il numero di istruzioni totali in un metodo.
- Il file NumeroIstruzioniTestatePerMetodo viene scritto nella classe StatisticsDataOrderer e contiene il numero di istruzioni eseguite in un metodo durante tutti i test.
- Il file FilePercorsi viene scritto nella classe MyTracerClass e viene letto nella classe StatisticsDataOrderer per scrivere il file CondizioniNonCoperte che dovrebbe contenere metodo-blocco e condizioni non coperte.
- Il file CondizioniNonCoperte viene scritto nella classe StatisticsDataOrderer.

-----

Ok perfetto grazie ora provo a vedere di fare qualcosa

-----

Ti dico un attimo come sono compisto i file FilePercorsi e CondizioniNonCoperte perché secondo me devo sistemare qualcosa.
Nel file FilePercorsi ogni riga è così composta:
- numero percorso;
- identificativo metodo-identificativo blocco
- valori booleani presenti nell'array passato al metodo tracer.
(Es.: percorso 1: org.junit.internal.requests.ClassRequest getRunner,Runner,; @1-true).

Se il matodo tracer viene invocato senza un array come parametro, non verrà scritta nessuna condizione dopo l'dentificativo del blocco.

Nel file CondizioniNonCoperte ogni riga è così composta:
- identificativo metodo-identificativo blocco
- condizioni non valutate durante l'esecuzione dei test per il corrispettivo metodo-blocco.
(Es.: junit.framework.Assert assertEquals,void,;String Object Object  @2 non valutate : false true;false false;true false;).

Per ora in questo file per ogni metodo-blocco risulta comparire la condizione false o false false o false false false... come non valutata perché esso viene scritto leggendo dal file FilePercorsi quali condizioni erano presenti nell'array.
Le condizioni false, false false.. (a seconda di quanti booleani prendono i controlli condizionali per entrare nel blocco) vorrebbero dire che il test non è entrato nel blocco e quindi non lo ha testato. Stavo pensando ad un modo per togliere questo tipo di condizioni dal file se i test non sono entrati nel blocco. 
Forse bisognerebbe controllare per ogni percorso del file FilePercorsi se durante l'esecuzione dal blocco iniziale a quello finale non è presente la stringa avente identificativo metodo-blocco o forse abbiamo già qualcosa di pronto.

Per far andare i test tramite interfaccia per pmd, dove hai rintracciato la posizione dei jars necessari mancanti?

-----
Hai ragione sarebbe un problema. Però teoricamente se in effetti le condizioni erano false-false per esempio e non è entrato nel blocco allora vuol dire che comunque lui le ha testate. Forse dovremmo fare in modo di mettere la cosa dei booleani prima dell'esecuzione del blocco.  
Però pensandoci meglio mi sembra abbastanza infattibile perchè il file procede riga per riga e non torna mai indietro quindi nel caso di espressioni su più righe saremmo fregati.
Però, se ci ragioniamo un attimo, è più o meno la stessa storia degli switch no? A noi serve sapere, quando entriamo nel blocco, le condizioni che sono verificate quando siamo al suo interno. Cioè con quali condizioni ci stiamo accedendo.  Quando non ci accediamo è ovvio che il predicato in sè è falso.  
Quindi secondo te possiamo lasciare così e far vedere le condizioni solo quando siamo dentro al metodo? Perchè altrimenti pensavo che in un predicato del genere  
```if(true && false){...}```  
il blocco non viene eseguito nonostante sia appunto sia true-false la condizione e non false-false. Quindi mi sa che invece di condizioni non testate è meglio mettere solo le condizioni testate per quel blocco. Cosa ne pensi?

Per quanto riguarda i jar li ho scoperti dalle eccezioni *NoClassDefFound*. Nel mio caso era solo una e sono andato nel build path di eclipse a vedere dove si trovava e ho messo quel percorso. 

-----
OK, ora il file CondizioniCoperte contiene metodi-blocchi con condizioni coperte, il file CondizioniNonCoperte non viene più scritto.
Ora ripasso un attimo per domani che ho un po' di ansia, se ci dovesse essere qualche problema con qualsiasi file(se scrivono dati sbagliati o altro), dimmelo pure perché per ora non ho ho effettuato l'esecuzione completa con tutti i test, ma con solo poche classi.

------
Son tornato poco fa, sisi non ti preoccupare ripassa pure ora guardo un po' i casi di test e vedo di fare qualcosa.  
Ho notato che c'è qualche problema con la storia dei path dei file che hai aggiunto da interfaccia. Se uno setta manualmente il percorso all'inizio del file va bene quindi per il momento bisogna farlo manualmente. Quando avremo finito tutto provvedo a sistemarlo.

Ho fatto partire tutto (tutti i casi di test di PMD e poi dopo ho fatto partire il StatistcDataOrderer) ma ci sono delle cose che non mi quadrano (magari è colpa di pmd per come è fatto):
- Nel NumeroIstruzioni.txt ci sono alcune righe che mi danno null come metodo (ho controllato in MetodiTirocinio e non ci sono quindi non penso derivi da lì l'errore) ti faccio un esempio di un pezzetto di file:  
```  
net.sourceforge.pmd.dcd.UsageNodeVisitor visit,Object,;MethodNode Object @10#1
net.sourceforge.pmd.dcd.UsageNodeVisitor visit,Object,;ClassNode Object @2#2
net.sourceforge.pmd.dcd.UsageNodeVisitor visit,Object,;ClassNode Object @4#2
null@22#1
null@12#1
null@1#1
null@2#1
null@20#1
```  
- **DatiStatistici** e **FilePercorsi** mi vengono file txt di 12MB l'uno è normale? (anche quelli ordinati ma è normale visto che sono delle "permutazioni" di quelli originali). Per **FilePercorsi.txt** non ho trovato stranezze mentre in **DatiStatisticiOrdinati** e quindi anche nel suo originale penso ci sia qualcosa di strano ti posto alcune righe:  
```  
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 1 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 10 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 100 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 1000 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 1001 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 1002 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 101 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 102 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 103 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 104 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 105 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 106 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 107 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 108 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 109 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 11 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 110 #i-1
net.sourceforge.pmd.AbstractPropertySource checkValidPropertyDescriptor,void,;PropertyDescriptor<?>  #c-1 @0 #v 111 #i-1
```  
e questo primo metodo va avanti ancora per un bel po' in questo modo. Dai un'occhio al parametro #v, è l'unico che cambia. Sono andato a vedere e #v dovrebbe essere il numero di volte che viene eseguito (quindi penso dovrebbe esserci una sola entry per quel metodo) invece qua mi sembra una specie di concatenazione di stringhe miste ad un incremento. E' giusto che faccia così?

- Ultima cosa è che ho aspettato un paio di minuti ma l'esecuzione del *StatistcsDataOrderer* non termina e vedo che il file **NumeroIstruzioniTestatePermetodo.txt** continua ad andare da 0kb a 23kb...poi torna a 0..poi va a 36kb..poi 0 ancora e poi di nuovo a 27kb. Quando interrompo manualmente l'esecuzione il file ha dentro una ventina di kilobyte di dati. Questo mi sembra abbastanza anomalo invece.
Fai pure con calma, dai un'occhiata più avanti e pensa all'esame di domani che questo non è urgente. Intanto provo a vedere qualcosa per il punto 5.

-----

I file DatiStatistici e DatiStatisticiOrdinati possono essere molto grossi perché sono i dati che venivano stampati a video originariamente durante l'esecuzione del metodo tracer. Le altre cose sono anomale e domani vedo di sistemarle, ma prima devo far funzionare i test via interfaccia per avere i file finali. Domani provo ad aggiustarli.

Sto eseguendo tutti i test da interfaccia, ma mi sa che il prolema non era dovuto a jars mancanti, ma forse a classi di test denominate in questo modo: package-info.java che contengono solo un commento e la dichiarazione del package (tipo package junit.samples;). 
Ho cancellato i file di questo tipo e l'esecuzione procede senza eccezioni. Il problema è che sto eseguendo i test da 20 minuti ed ora l'esecuzione è ferma al 33esimo package di test che contiene una classe chiamata FailOnTimeoutTest che contiene questo campo:

    private static final int DURATION_THAT_EXCEEDS_TIMEOUT = 60 * 60 * 1000; // 1
                                                                             // hour
non vorrei che il test durasse un'ora, ma può essere. Mancano ancora 9 package, ma in questo modo non posso testare i file che stavo costruendo quindi forse per ora elimino la classe e provo a sistemare i file eseguendo gli altri 9 package di test.

-----

Ok com'è andato l'esame?
ora faccio un commit. Ho aggiunto una copertura dei test, cioè il numero di blocchi testati da quella classe di test. L'ho messa nel file TestCoverage.txt. E cambiato una cosa:
nel file percorsi è sbagliato come viene caratterizzato un percorso. Un percorso è caratterizzato sì dal numero di esecuzione ma anche dal particolare metodo da cui parte l'esecuzione (ti faccio un esempio)  
Se due metodi A e B vengono chiamati essi fanno partire un percorso. Se supponiamo che il metodo A viene chiamato 3 volte alla terza volta la dicitura del percorso attuale sarà percorso 3: bla bla bla...ma se anche B viene chiamato 3 volte il percorso sarà percorso 3: ble ble ble. Quindi sarebbero percorsi chiamati uguali ma son diversi. Ho aggiunto in modo tale che sia percoso A3 o percorso B3. (ovviamente aggiungendo altre parti il file viene ancora decisamente più grande (tipo 20 MB a me).  
Ora committo.

Per il problema del timeout non so come aiutarti. A me con pmd funziona (più o meno) tutto e in un minutino me li fa tutti.  
Sto cercando di collezionare dati sui test e stavo pensando: alla fine dei conti ci serve sapere (oltre alle altre millemila cose) il totale dei blocchi che abbiamo nel codice, il totale dei metodi e quali metodi/blocchi sono testati.  
Allora ho pensato di usare il countMap.size() per sapere quanti blocchi ci sono nel codice ma poi se ci pensi nel countMap non ci sono tutti i metodi e i blocchi del codice. Infatti questa viene aggiornata solo quando viene chiamato il metodo tracer. E il metodo tracer viene chiamato dai test e solo quando questi vengono eseguiti o passano di là. Quindi in fin dei conti i file che abbiamo estrapolato non tengono conto di tutte le condizioni di tutti i blocchi ma solo quelli registrati dai test. Mi sbaglio? Allora ho pensato di inserire una lista con tutti i blocchi a partire dal preprocessing e non nella classe MyTracerClass. Per ora mi sto muovendo in questa direzione. Quindi bisogna stare attenti anche se gli altri file si riferiscono solo ai dati di test o ai dati globali del codice.  
p.s. forse ho capito perchè mi dava *null* su alcuni metodi/blocchi. Suppongo dipenda da PMD (o ma va toh che novità..) visto che ogni tanto mi da questa eccezione: 
```Java
net.sourceforge.pmd.RuleSetNotFoundException: Can't find resource 'null' for rule 'java-basic'.  Make sure the resource is a valid file or URL and is on the CLASSPATH. Here's the current classpath: F:\Documenti - Marco\... eccetra eccetra
```
Non so magari dipende da questo.

------

OK, ora i test scrivono, ma ad un certo ppunto si bloccano e non scrivono più sui file (da interfaccia il bottone Run Tests rimane premuto quindi non dovrebbe aver terminato l'esecuzione).
Stavo mettendo a posto il metodo per il file CondizioniCoperte che elaborando i dati del file FilePercorsi (4,4 MB) scrive un file di 5,78 KB (CondizioniCoperte.txt) non so quanto sia possibile, se vuoi faccio il commit così lo provi anche tu visto che i miei file di dati derivanti dai test dovrebbero essere incompleti.


------

C'è qualcosa che non va. Allora fammi fare un riepilogo completo così ho un quadro chiaro dei file e cosa contengono (e quanto ci aspettiamo siano grandi):  

- **MetodiTirocinio.txt** contiene l'elenco di tutti i metodi rilevati da ASTParser. E' scritto nella forma:  
 ```Nome metodo```  
Ci si aspetta che contenga una entry per ogni metodo. PMD ha quasi 6000 metodi (da metrics). Quello che rilevo dopo il test sono quasi 5300 righe. Viene scritto da ASTParser ogni volta che incontra la dichiarazione di un metodo (non tiene conto delle dichiarazioni di metodi interni ad altri metodi). *Dimensione: 457Kb*
- **Blocks.txt** contiene l'elenco di tutti i blocchi. E' scritto nella forma:  
 ```Nome metodo + @ + numero blocco```  
Ci si aspetta che contenga una entry per ogni blocco con il tracer dentro. PMD ha quasi 6000 metodi, contati 5300. Quello che rilevo dopo il test sono quasi 10000 righe. Con una media di 1,88 blocchi per ogni metodo potrebbe sarebbe fattibile. Viene scritto nel MyTracerClass ogni volta che viene inserito un tracer() nel codice. *Dimensione: 907Kb*
- **NumeroIstruzioni.txt** contiene il numero di istruzioni che finiscono con il ; per ogni blocco di codice. E' scritto nella forma:  
 ```Nome metodo + @ + numero blocco + # + numero di istruzioni```  
Ci si aspetta che contenga una entry per ogni blocco con il tracer dentro. Secondo il file precedente sono almeno 10000 blocchi. Quello che rilevo dopo il test sono poco meno di 3300 righe. Dovrebbero essere almeno tanti quanti i blocchi nel file Blocks se conta anche i blocchi con 0 istruzioni. Viene scritto nel FileParser ogni volta che finisce il preprocessing di un file. *Dimensione: 313Kb*
- **FilePercorsi.txt** contiene i blocchi percorsi per ogni cammino, dove un cammino è originato da ogni esecuzione di ogni metodo chiamato dai test. E' scritto nella forma:  
 ```"percorso" + nome metodo  che ha originato il percorso + * + n-esima volta che viene eseguito quel metodo + : + nome del metodo eseguito + @ + numero blocco + - + valore delle condizioni che hanno permesso l'entrata nel blocco (se presenti)```  
Indefinito il numero di percorsi, soprattutto se un metodo viene eseguito in un ciclo dando origine più percorsi uguali. Quello che rilevo dopo il test sono poco meno di 130'000 righe.Non si sa quanto dovrebbero essere. Viene scritto in 2 metodi nel MyTracerClass. *Dimensione: quasi 20Mb*
- **TestCoverage.txt** contiene il numero di blocchi di codice testati per ogni classe di test eseguita. E' scritto nella forma:  
 ```Nome classe + #c + numero di blocchi attraversati```  
Ci si aspetta che contenga una entry per ogni classe di test. Secondo metrics PMD ha 256 classi. Quello che rilevo dopo il test sono 229 righe. Viene scritto nel MyTracerClass ogni volta che finisce l'esecuzione di una classe di test da interfaccia. *Dimensione: 15kb*
- **FileStatistici.txt** contiene per ogni blocco il cui tracer viene eseguito,il tipo di blocco, il numero di istruzioni e il numero di volte che viene eseguito. E' scritto nella forma:  
 ```Nome metodo + #c + tipo di blocco + @ + numero blocco + #v + numetro di volte eseguito + #i+ numero di istruzioni```  
Ci si aspetta che contenga una entry per ogni blocco con il tracer dentro. Secondo i file precedenti sono circa 10000 blocchi. Quello che rilevo dopo il test sono poco meno di 135'000 righe. Dovrebbero essere tanti quanti i blocchi nel file Blocks. Viene scritto nel MyTracerClass ogni volta che viene eseguito il metodo tracer() dai test. *Dimensione: quasi 12Mb*
- **FileStatisticiOrdinati.txt** contiene ciò che è contenuto nel file precedente ma in ordine alfabetco. E' scritto nella forma:  
 ```Nome metodo + #c + tipo di blocco + @ + numero blocco + #v + numetro di volte eseguito + #i+ numero di istruzioni```  
Ci si aspetta che contenga una entry per ogni riga del file FileStatistici. Nel file precedente ho poco meno di 135'000 righe. Quello che rilevo dopo il test sono poco meno di 135'000 righe. Viene scritto nel StatisticDataOrderer. *Dimensione: quasi 12Mb*
- **NumeroIstruzioniTestatePerMetodo.txt** contiene per ogni metodo il cui tracer viene eseguito dai test il numero di istruzioni dei blocchi eseguiti. E' scritto nella forma:  
 ```Nome metodo + "numero: " + numero di istruzioni testate per quel metodo```  
Ci si aspetta che contenga una entry per ogni metodo testato. Secondo i file precedenti sono circa 5300 metodi. Quello che rilevo dopo il test sono poco più di 3600 righe. Dovrebbero essere al massimo 5300 righe. Viene scritto nel StatisticDataOrderer. *Dimensione: 62kb*
- **GlobalData.txt** contiene la percentuale e il numero dei blocchi testati e non rispetto al totale. E' scritto nella forma:  
```
Total block code: + numero blocchi totali
Total block code tested (cumulative): + numero di blocchi testati in totale dai test
Total block code tested: + numero di blocchi unici testati dai test
Uncovered block: + numero di blocchi mai testati dai test
% test coverage: + percentuale di copertura
% test uncovered: + percentuale di non copertura
```
Ci si aspetta che i dati siano verosimili. Viene scritto nel MyTracerClass alla fine dell'esecuzione dei test *Dimensione: 1kb*
- **CondizioniCoperte.txt** contiene l'elenco delle condizioni per entrare in alcuni blocchi, che sono state testate dai test. E' scritto nella forma:  
 ```Nome metodo + @ + numero blocco + " valutate: " + elenco condizioni valutate```  
Ci si aspetta che contenga una entry per ogni blocco che è stato testato che con il metodo tracer(...., booleanarray). Ci sono al massimo 10000 blocchi. Quello che rilevo dopo il test sono quasi 2300 righe. Dovrebbero essere al massimo tanti quanti i blocchi totali. Viene scritto nel StatisticDataOrderer elaborando il FilePercorsi. *Dimensione: 34Kb*.

Come vedi ci sono un bel po' di incongruenze. L'errore che mi è saltato all'occhio è sul FileStatistici. E' sbagliato dove viene scritto perchè ogni volta che viene eseguito un tracer fa una riga ma se il tracer di quel metodo viene eseguito tipo 10 volte questo fa 10 righe con "esecuzione 1, esecuzione 2, esecuzione 3... ecc" . Quindi bisogna farlo scrivere alla fine di tutto quando il numero di esecuzioni è stato stabilito.  
AstParser non legge tutti i metodi di Metrics però ce se ne può fare una ragione.  
Guarda anche il NumeroIstruzioni. Fa un terzo delle righe che dovrebbe fare da me. (anche se ho visto che c'è una condizione che mette solo le righe con + di 0 istruzioni ci sono righe con 0 istruzioni contate quindi non so se è giusto così o no).  
Un altro errore è sul NumeroIstruzioniTestatePerMetodo.txt non capisco perchè ma continua a fare quella stranezza che sembra impallarsi e ci mette una vita a scrivere (fa al solito 0kb...20kb...0kb...36kb ecc). L'ho lasciato andare un paio di minuti e poi ha finito con il file che ti ho detto. Non so ancora perchè.  
Per quanto riguarda invece il CondizioniCoperte potrebbe anche essere giusto se vedi il numero delle righe. Dipende da come sono i blocchi ma bisognerebbe testare con qualcosa di semplice.  
Se puoi leggi tutto quello che ho scritto sopra e correggi/edita pure quello che vedi di sbagliato perchè sui file che hai messo tu non sono sicuro di aver capito se quello che devono fare è proprio quello che ho scritto.

-------

Finalmente dopo 2 ore è finita l'esecuzione delle classi di test.
Il FilePercorsi occupa 607 MB il file DatiStatistici occupa 396 MB.

Ho dei dati sorprendenti:

- Total block code: 1636
- Total block code tested (cumulative): 3928427
- Total block code tested: 1402
- Uncovered block: 231
- % test coverage: 85.69682151589242
- % test uncovered: 14.119804400977994

--------
Ahah ma va? Allora può anche darsi che funziona il calcolo e che quelli di PMD abbiano fatto poco nulla di testing.  
Mi sembra comunque ragionevole che quelli di Junit facciano un lavoro fatto meglio sui test. 85% se è veramente così è buona buona.  
Certo che 2 ore di esecuzione di test mi sembrano belle toste. Ci sarà qualcosa veramente tipo sul timeout (magari prova a settarlo a 1 minuto invece che un'ora, giusto per curiosità XD).  
Mi sa che dovremo fare qualcosa per quei file..miseria son troppo grandi!
Quel lavoro lo faccio domani alla fine che oggi non ho più avuto tempo.

-----

Sto facendo andare la classe StatisticDataOrderer da circa 4 ore, ma l'esecuzione non si è ancora arrestata, faccio andare tutta notte e poi vedo...
Alla fine il file CondizioniCoperte è di 32 KB. Credo ci abbia messo un po' più di 4 ore per terminare.
In tutto, tra test ed elaborazione per altri file, credo siano passate un po' più di 6 ore.

----

Decisamente troppo direi. Ci sarà qualche errore. Io ho sistemato quello che dovevo e fatto partire tutto: 
- Datistatistici ora ha poco più di 10000 righe e 1MB di dimensione
- FilePercorsi 23MB
- NumeroIstruzioni ha sempre 3300 righe. Quindi mi sa che non era quello l'errore
- GlobalData ora mi dice che c'è l'11% coperto e il 91% non coperto (mistero)
- Devo sistemare un errore su numeroIstruzioniperMetodo che mi da tutto a 0
- CondizioniCoperte 35kb e 336 righe

------

Scrivo ancora 2 cose sui miei file perché visto il tempo che ci vuole per ottenerli, mi sa che li tengo buoni per un po' e me li salvo da qualche parte (I miei file sono stati ottenuti fino al mio ultimo commit e non comprendono le tue ultime modifiche).

I file più grossi sono:

- DatiStatistici 396 MB
- DatiStatisticiOrdinati 279 MB
- FilePercorsi 607 MB

Si vede subito che i file DatiStatistici e DatiStatisticiOrdinati non hanno la stessa dimensione anche se quest'ultimo dovrebbe solo riordinare le stringhe.
Dei rimanenti il più grande è Blocks con 124 KB.
Il i dati del file GlobalData mi sembrano plausibili visto il tempo impiegato per effettuare i test e visto il numero cumulativo dei blocchi testati.
La classe StatisticDataOrdere ci ha messo 4 ore e l'esecuzione più lunga è stata quella del metodo writeCoveredConditions() in cui bisognava esaminare riga per riga il file FilePercorsi ed inserire nell'HashMap i metodi non presenti ed effettuare alcuni calcoli. FilePercorsi nel mio caso è enorme e penso ci abbia messo un sacco per leggerlo e poi per effettuare il controllo nell'HashMap se fosse o no presente un metodo avente stesso nome. La scrittura del file CondizioniCoperte penso sia avvenuta molto velocemente.

-------

Ok, si ti conviene tenerli. Con le mie modifiche il file dei DatiStatistici viene più o meno lungo quanto il file Blocks. PErò ti conviene aspettare che tutto sia sistemato prima di rieffettuare i test. Comunque sembra che non fosse quello il problema sul NumerIstruzioni. E' ancora corto. Devo pensare a qualcosa e sistemare anche gli altri (e capire perchè 91%+11% fa 102%. devo capire anche da dove esce quel 2% in più di blocchi.
A me DatiStatistici e DatiStatistici ordinati sono grandi uguali.

------

Ho tolto un bel po' di sysout e ho scoperto che quei *null* che mi dava nei file al posto del nome del metodo è il responsabile dell'errore sulla % errata nel global test.  
Il fatto che ci siano i null deriva dal fatto che ASTParser non legge le classi dichiarate come enumerativi (enum al posto di class) e tutti i metodi/blocchi al suo interno vengono contati null perchè non sono presenti nel file "metodiTirocinio" che fa ASTParser. Provo a vedere se riesco a fargli parsare gli enum.

---------

Sto provando a far andare i test, ma il FilePercorsi ogni tanto mi si azzera. Prima mi sa che non lo faceva. 

-----

Cavolo ora controllo. Sul mio ho provato e non lo fa non so cosa possa essere

-----

Può essere qualche eccezione? Anche se non penso perché i package-info li ho eliminati

------ 
Non lo so. Ho ricontrollato e non mi sembra ci siano errori. Però ho visto che ci siamo dimenticati di far riconoscere i block finally e i syncronized. Non penso sia per quello però dovrebbe trovare qualche blocco in più (p.s. i blocchi synchronized sono difficili da prendere perchè possono essere anche synchronized i metodi quindi li prende solo quando i blocchi hanno una parentesi tonda subito dopo il "synchronized".)
Ma ti si resetta una sola volta o tante? Con che frenquenza più o meno? Può essere che fosse qualcosa tipo quell'altro file che mi faceva la stessa cosa a me?

Son riuscito a far partire quella classe di test base che non riusciva a partire. I file son tutti i giusti tranne il FileIstruzioni che mi conta 2 istruzioni in un solo blocco quando in realtà è una in 1 blocco e l'altra in un'altro. A parte questo c'è un problema. Il FilePercorsi ogni tanto non viene creato, forse è relativo al tuo problema. Ora provo a vedere cosa lo causa.

-------

Mi si resetta tante volte, forse per ogni test, quindi abbastanza frequentemente. I test stanno andando da 4 ore (sono ritornato da poco) e non sono terminati ancora. Adesso vedo qual è il problema anche se dal nome del test mi pare che non possa risolvere.
I test base io li avevo fatti partire da eclipse direttamente perché da interfaccia non capivo bene come farli partire.

Boh, non capisco vermente dove sia il problema e perché ce l'ho solo io, non c'è nessuna eccezione e il file si azzera casualmente. In più, prima rimaneva fisso al 49% ora l'ho fatto ripartire ed è al 59%....

------
Purtroppo non saprei. Che sia un problema sullo stream o sulla condizione firstTime nel myTracerclass?  
Per la barra non so, dovrebbe essere giusta quindi penso si fermi in 2 punti diversi dei test. Proverò a mettere nella label il test in esecuzione. p.s. stasera non posso che non ci sono

-------

Non credo che sia un problema della barra, penso sia un problema legato alla casualità dei test (secondo me rendono casuale l'esecuzione quelli di junit).
Io sto facendo ancora andare il tutto e ho tolto anche il timeout. L'unica cosa è vedere se il problema è solo mio a questo punto, magari quando non devi fare più altro e se hai voglia, prova a far andare il programma su Junit

Entro fine settimana mandiamo una mail al prof?

----------------------------

Va bene appena abbiamo terminato le cose principali proverò anche io con Junit.  
Ho guardato la mail del prof e ho cercato di aggiungere qualche dato in più che ci chiedeva. Ora ti spiego:  
- Nel GlobalData ora sono presenti quanti cammini ci sono, quant'è la lunghezza media per ogni cammino e il numero totale di blocchi nei cammini (ovvero se il cammino A è così composto percorso A = C -> D -> F -> M allora la lunghezza di A è 4. Se c'è un altro cammino uguale ad A allora il totale è 8. Invece i blocchi testati saranno 10 (ossia i 4 blocchi del cammino più i due metodi A). Questo è per spiegare perchè il *Total block code tested (cumulative)* è più grande del *Total number of path-block covered*.
- Nel test coverage invece sono presenti 4 dati in più: 
	- **#ub** sta per unique block e rappresenta il numero di blocchi testati in più. Cioè il numero di blocchi che prima non erano testati e che aggiunge rispetto a prima.
	- **#ubp** è la percentuale di blocchi unici rispetto al totale dei blocchi
	- **#b** è il numero di blocchi unici che testa (indipendentemente se questi sono già stati testati da un'altra classe)
	- **#bp** è la percentuale di blocchi unici (senza tener conto di quelli prima) rispetto ai blocchi totali.

Altro accorgimento. Ho rimosso la parola *percorso* quando viene scritto il FilePercorsi così dovrebbe diminuire di un pochino la dimensione non dovendo riscrivere per tot-mila volte quella parola.  
Mi sono accorto che comunque c'è un errore per il riconoscimento dei percorsi:  
quando c'è un metodo ricorsivo il metodo richiama sè stesso quindi il nome del metodo chiamato coincide con il metodo che ha originato il percorso causando la fine di questo e iniziandone un altro per ogni chiamata ricorsiva subita. Bisogna decidere se fixarlo o no. Al momento non ho idea di come poter fare.

Guardando la mail del prof ci chiedeva anche di calcolare la similarità di vari percorsi. Ho un'idea di come si potrebbe fare però questo richiederebbe il processing un po' elaborato del FilePercorsi. Essendo questo molto grande (soprattutto nel tuo caso) sarebbe abbastanza lunga la procedura (penso). Dopo provo a farla (la aggiungo nel post processing nel *StatisticsDataOrderer*, poi eventualmente decidi tu se commentare l'esecuzione di quel metodo per evitare di allungare ulteriormente l'esecuzione.

Per la mail va bene, entro domenica scriviamo.

--------

I miei problemi sono quello dell'azzeramento del FilePercorsi, che non capisco perchè a me si azzera delle volte e con PMD no e poi che non mi finsce l'esecuzione dei test. Il primo pensavo fosse il booleano che dice se è la prima volta che viene scritto il file, però se a te non lo dà non lo so cosa potrebbe essere..
Per il secondo problema non c'è niente da fare, ho provato ieri pomeriggio a farlo andare per più di 4 ore e anche stamattina, ma niente. A sto punto spero che sia qualche problema mio

Ora effettivamente non so come aiutarti per andare avanti, se mi dici qualcosa da fare provo a farla

-----
Guarda, attualmente non sto testando nulla su pmd. Sto facendo tutti i test sui file di prova.  
Guardando la mail ci mancherebbe da fare questo:
- Analisi delle frequenze delle diramazioni
- Analisi delle frequenze di porzioni di cammino 
- Analisi del procedere della copertura (un pezzetto l'ho già fatto prima, cioè nel mettere quanta copertura per classe di test) bisognerebbe analizzare quello che chiede il prof
- chiamate effettuate a metodi della stessa classe e chiamate effettuate a metodi di altre classi (qua ci aveva dato il link però non so quanto sia fattibile)

Dimmi tu cosa preferisci fare.

Dimentica la storia delle frequenze delle diramazioni che si differenziano...verrebbe una struttura dati per ogni entry del percorso (decisamente infattibile). L'idea era sbagliata. Non saprei, se hai idee fai pure. Provo con l'analisi del procedere della copertura

Ho aggiunto statistiche al GlobalData e al TestCoverage.  
Per quanto riguarda il TestCoverage ti spiego cosa vogliono dire:  
**#tnc** vuol dire quanti classi di test come questa sono necessarie per raggiungere il 50%-75%-85% di copertura dei blocchi  
**#tnt** vuol dire in media quanti test case come quelli di questa classe sono necessari per raggiungere il 50%-75%-85% di copertura dei blocchi  
Per quanto riguarda i nuovi dati sul GlobalData si dovrebbero capire, se non capisci scrivi che ti spiego cosa vogliono dire (p.s. negli ultimi dati un numero negativo indica quanti bisognerebbe toglierne per raggiungere quell'obiettivo di copertura, nel caso in cui l'obiettivo sia già stato raggiunto e superato)


TODO LIST
=========

####### Task principali (maggiore urgenza)

- [x] Trovare la giusta nomenclatura per i file sorgenti
- [x] Far fare all'interfaccia grafica il preprocessing
- [x] Risolvere errori per l'esecuzione test di JUnit
- [ ] Gestire nel MyTracerClass i dati raccolti (tipo mostrarli in un formato leggibile o farci gli esperimenti statistici)

-------

####### Task secondari (non indispensabili)

- [ ] Gestire situazioni di errore interfaccia e non
- [ ] Codice per contare le istruzioni all'interno dei metodi ma fuori dai blocchi
- [x] Codice per passare al myTracerClass il conteggio delle istruzioni
- [ ] Gestire ASTParser per fargli riconoscere i metodi dichiarati internamente a istruzioni

 
------
 
Tirocinio
=========

parsing logical boolean expressions java --> stringa di ricerca


- [x] per ogni esecuzione di metodo tenere traccia dei vari cammini (1)
 	- [x] modificare il mytracer (inizia a registrare quando trovi una chiamata con codice -1)

- [x] condition coverage (2)
	- [x] cercare parser espressioni
	- [x] inserire istruzioni prima dei blocchi if per sapere il valore della condizione
	- [x] tenere traccia delle condizioni

- [x] copertura delle istruzioni interne ai blocchi (3)
	- [x] cercare un tool che tenga conto del numero istruzione
	- [x] contare i punti e virgola in caso negativo
	- [x] sapere quante istruzioni per blocco e tenerne traccia

- [ ] interfaccia grafica (4)

- [ ] copertura dei casi di test (5)
	- [ ] alla fine di ogni classe di test sapere quanto si è coperto del totale
	- [ ] giocare con le statistiche