NUnit Primo test molto lento con Entity Framework nel runner di prova Resharper

Question

Esiste una soluzione alla lentezza del primo test NUnit quando si utilizza Entity Framework 4.1?

sto trovando ci vogliono circa 10 secondi per la prima prova, il resto dei miei test sono in esecuzione in 0.01 secondi (a seconda dell'opzione ReSharper Show Time)

Se si esegue il test utilizzando la GUI NUnit, ancora una volta prima prova dura 10 secondi, ma se ho ri-eseguire l'intero set di test viene eseguito in meno di 0,5 secondi ... fino a quando ho ricompilare la soluzione

ho anche un test NUnit di un Servizio WCF ospitato in IIS, che chiama EF, e il primo termina in circa 3 secondi. Quindi se rieseguo i test, è giù per 1 secondo e, come previsto, su ricompilare la prima volta è di nuovo a 3 secondi.

Ma i test originali NUnit, che sono contro una libreria di classi con metodi chiamando EF, sono sempre intorno alla seconda soglia dei 10, cioè nessuna diminuzione nel tempo

Ok, ho capito che IIS sta facendo "qualcosa "[cosa?], ma in entrambi i casi sto usando NUnit per effettuare le chiamate ... perché uno è 10+ secondi per la prima chiamata, l'altro è 3 secondi e poi 1 secondo per le chiamate successive ??

E per davvero confondermi, ho scritto una semplice app per console che chiama uno degli EF utilizzando i metodi nella classe in fase di test e che riesce a completare in 1 secondo.

UPDATE ... gli stessi test ri-scritti come test MSTest finire il primo test in circa 3,5 secondi, che è paragonabile alla prima prova nel corridore NUnit GUI, in modo che il problema sembra essere la ReSharper test runner per NUnit in Visual Studio

UPDATE 2 ... sì, il problema sembra essere il runner di prova di Resharper. TestDriven.NET e Visual Nunit 2010 sono entrambi più veloci.

UPDATE 3 ... ed è ora registrato con JetBrains come una questione

Answer 1

Questo è un comportamento comune, perché il primo test dovrà compilare "viste EF" - questo accade prima volta che si utilizza nulla mappato in il tuo modello Le stesse viste compilate vengono quindi memorizzate nella cache e riutilizzate. Può essere evitato ma richiede di generare manualmente il codice per le viste (by using EdmGen.exe), aggiungere quel codice al progetto e compilarlo insieme alla soluzione. Dovrai farlo ogni volta che cambi qualcosa in EDMX a meno che non lo fai come un'azione pre-build nel tuo progetto (a sua volta rallenterà la tua build).

Answer 2

La differenza tra i vari corridori può essere dovuta alla piattaforma (x64 vs x86) che stanno utilizzando. EF è molto più lento per iniziare in modalità x64.