Organizzazione test di integrazione/unità in una soluzione Large Visual Studio

Question

Sto iniziando a sviluppare e organizzare i test per una soluzione di Visual Studio di grandi dimensioni. (Sì, so che i test avrebbero dovuto essere sviluppati insieme al codice piuttosto che quando il progetto è quasi completo, ma le cose sono quello che sono.)

Ho visto domande simili sull'organizzazione dei test unitari in soluzioni Visual Studio , ma non ho visto nessun test di integrazione degli indirizzi. Gradirei alcune indicazioni su dove posizionare i progetti di test in modo che non ingombrino la già grande base di codice.

Ecco la gerarchia di base delle cose all'interno della soluzione. (Tutti gli articoli non terminano in .proj sono cartelle all'interno di un progetto o cartelle soluzione.)

• HardwareServices
  • HardwareService1
    • HardwareService1.Core.proj
    • HardwareService1.Host.proj
    • HardwareService1.Service.proj
  • HardwareService2
    • HardwareService2.Core.proj
    • HardwareService2.Host.proj
    • HardwareService2.Service.proj
• Infrastrutture
  • MyApp.Database.proj
  • MyApp.Infrastructure .proj
  • MyApp.ReportViewer.proj
  • MyApp.SettingsManager.proj
• AppModules
  • AppModule1.proj
    • comune
    • Reports
    • Servizi
    • ViewModels
    • Visualizzazioni
  • AppModule2.proj (struttura simile ad altri AppModules)
  • AppModule3.proj (struttura simile ad altri AppModules)
• Moduli
  • ComputeEngine.proj
  • Footer.proj
  • Header.proj
  • CommonServices.proj

Il mio pensiero è stato quello di fare una cartella della soluzione denominata "Test" e quindi imitare la gerarchia di cui sopra, facendo progetto di una prova per ogni progetto di codice di produzione. All'interno di ogni progetto di test, creo cartelle chiamate "UnitTests" e "IntegrationTests".

Il mio obiettivo è creare uno schema di denominazione/organizzazione coerente in modo che non ci siano ambiguità su dove dovrebbero essere effettuati i nuovi test e dove trovare i test esistenti. Data la grande dimensione di questo progetto/applicazione, mi piacerebbe ottenere la struttura abbastanza solida proprio fuori dal cancello in modo che non sia un dolore dopo.

Grazie per il vostro tempo e i vostri consigli.

Answer 1

La convenzione di denominazione adottata dalla nostra azienda era l'uso di projectName.Tests.Unit e projectName.Tests.Integration.

Con la vostra struttura esistente si dovrebbe avere qualcosa di simile:

• HardwareService1
  • HardwareService1.Core.proj
  • HardwareService1.Host.proj
  • HardwareService1.Service.proj
  • Test
    • HardwareService1.Core .Tests.Unit
    • HardwareService1.Core.Tests.Integration

Se mantenere la cartella di test insieme alla cartella principale non si dispone di imitare di nuovo la struttura completa come il i test sono giusti con il rispettivo progetto.

nota a margine

Avendo il nome del progetto con un consistente Tests.Unit aiuta assistere nella gestione di unit test nel vostro script di build, come è possibile eseguire i test con una ricerca jolly come **\*tests.unit*.dll

Alla fine della giornata, la struttura del progetto può essere molto soggettiva, quindi fare ciò che ha senso nel proprio ambiente e ha senso per la propria squadra.