Domanda

A causa di alcune configurazioni sulla mia macchina dev sono stato costretto a spostare il mio codice per i "Documents and Settings" cartelle. Dato che il nostro #? *% & $ £ "amato" per forza di VCS può avere problemi con i percorsi di file lunghi in scenari specifici, ho mappato un drive (V :) per puntare al codice. Questo funziona generalmente ora con una sola eccezione: per qualche ragione, i corridori di unit test integrati in VS non possono eseguire più test. Specificamente ho provato questo utilizzando TestDriven.NET e il test runner ReSharper. Entrambi mostrano lo stesso comportamento strano: nessun errore, i test sono solo non funzionano

.
  

0 Passa, 0 non riuscito, 0 saltati

Quando apro la soluzione da C: \ Documents ... ed eseguire le prove utilizzando dette corridori, funziona:

  

211 passavano, 0 non riuscito, 0 saltati

ho il sospetto di un problema a 64 bit (siamo su Win7 Ultimate x64). Ma le linee di prova sono impostati su "Qualsiasi CPU", entrambi i corridori in grado di gestire questo scenario e reindirizzamento per gli eseguibili NUnit appropriate (... per quanto posso dire, mi corregga se sbaglio!). Aprendo le linee di prova con la GUI NUnit sia da C: \ e V: \ lavoro benissimo.

posso solo supporre questo ha a che fare con i corridori in VS non essendo in grado di richiamare i test quando i percorsi dei file si riferiscono a un'unità mappata ... ma questo suono piuttosto strano, quindi speravo alcuni di voi hanno visto questo problema prima e può dare qualche consiglio.

Per bollire questo fino a una domanda:
Qualcuno ha mai avuto problemi con NUnit corridori di prova in VS 2010 non eseguire test, forse a causa della soluzione di essere su un'unità mappata?

Win 7 Ultimate x64
VS 2010 Ultimate
NUnit 2.5.8
TestDriven.NET 3
ReSharper 5.1

È stato utile?

Soluzione 2

OK, abbiamo finalmente trovato un modo per aggirare questo. Mentre non abbiamo davvero risolvere il problema con il nostro mappato V: unità essendo un'unità di rete, funziona bene se si crea l'unità mappata utilizzando il SUBST comando.

La differenza qui è che il V: unità è stata trattata come un percorso di rete da quando ho creato la mappatura con "unità di rete" nel menu di Esplora risorse (che credo sia equivalente al comando NET ). Questo può portare a problemi di fiducia quando le assemblee sono chiamate tra la rete e le unità locali. Alcuni ragazzi anche ottenuto i messaggi di errore durante costruisce lungo le linee di

  

eccezione non gestita:   System.Security.SecurityException:   Che il montaggio non consente parzialmente   fiducia chiamanti.

Utilizzando SUBST nostri V: i punti di unità a un locale (= fiducia) posizione, e ora i nostri test tutti corrono come previsto

.

Per creare un'unità mappata con SUBST, procedere come segue. Questo esempio mappe una nuova unità "V" virtuale alla posizione codice degli utenti (= [yourName]) cartella:

  

C:> subst v: C: \ Users [yourName] \ codice

Altri suggerimenti

Non ho provato. Ma solo un pensiero. Si può verificare il percorso degli eseguibili per TestDriven.Net così come NUnit. Si potrebbe anche voler controllare il riferimento al progetto di test. è relativo o assoluto?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top