Limitazioni dell'utilizzo di C ++ / CLI con NUnit

Question

Questa risposta a una domanda sui framework di test unitari C ++ suggerisce una possibilità che non mi era mai venuto in mente prima: usando C ++ / CLI e NUnit per creare unit test per il codice C ++ nativo.

Usiamo NUnit per i nostri test C #, quindi la possibilità di usarlo anche per C ++ sembra allettante.

Non ho mai usato il C ++ gestito, quindi la mia preoccupazione è che ci sono limiti pratici a questo approccio? Molti di voi lo stanno facendo? In tal caso, com'è stata la tua esperienza?

Answer 1

Lo facciamo sempre. Abbiamo molti assembly scritti con C ++ / CLI e utilizziamo C # e NUnit per testarli. In realtà, poiché il nostro obiettivo è fornire assiemi che funzionino bene con C #, facendo questo ci assicuriamo di averlo raggiunto.

Puoi anche scrivere test NUnit in C ++ / CLI e chiamare C ++ non gestito. Probabilmente il modo migliore è mantenere il tuo C ++ puro non gestito in una lib, quindi creare un assembly di test che utilizza NUnit e si collega alla lib.

Answer 2

Funziona molto bene e ti dà il vantaggio di avere test con parametri, nonché un runner e un framework di test comuni se ti trovi in ??un ambiente misto.

Ci sono due aspetti negativi, nessuno dei quali è grave per la maggior parte dei casi:

1. Se sei molto esigente, i test non vengono più eseguiti in un ambiente puramente nativo, quindi c'è una possibilità esterna che qualcosa possa funzionare sotto test ma fallire in fase di esecuzione. Penso che dovresti fare qualcosa di abbastanza esotico perché questo abbia importanza.

2. Fai affidamento sul fatto che il tuo codice C ++ possa essere incluso in un programma C ++ / CLI. A volte questo può avere scontri con le intestazioni e costringe il tuo codice a costruire OK con UNICODE. In generale, questa è una buona cosa in quanto scopre frammenti di codice (come l'uso incoerente delle varianti Ansi delle chiamate Win32). Tieni presente che sono solo le intestazioni incluse, quindi ciò che potrebbe mostrare è che stai esponendo le intestazioni a un livello troppo alto - alcune delle tue inclusioni dovrebbero probabilmente essere all'interno dei tuoi file di implementazione cpp.

Answer 3

La mia esperienza è che non è possibile utilizzare NUnit per testare il codice nativo C ++ tramite C ++ / CLI perché avresti problemi a caricare e utilizzare il codice nativo.

Ho provato a usare nunit per caricare un dll di prova c ++ / cli di base collegato a " solo thread " che è un'implementazione della libreria di thread standard c ++. Le DLL di prova non verranno nemmeno caricate con l'ultima versione di NUnit (2.6.2).

Quindi sicuramente non è la strada da percorrere!

Answer 4

Non ne ho mai usato uno, ma non c'è una porta? Forse http://cunit.sourceforge.net/documentation.html funzionerebbe per te.

Answer 5

La principale preoccupazione è la curva di apprendimento del linguaggio C ++ / CLI (precedentemente Managed C ++), se i test devono essere compresi o mantenuti da sviluppatori non C ++.

Sono necessari almeno 1-2 anni di esperienza OOP in C ++ per poter contribuire a un progetto di test CLI / NUnit C ++ e risolvere i vari problemi che sorgono tra le interfacce di codice nativo gestito. (Per contributo, intendo essere in grado di lavorare autonomamente e in grado di creare oggetti simulati, implementare e utilizzare interfacce native in C ++ / CLI, ecc. Per soddisfare tutte le esigenze di test.)

Alcune persone potrebbero non cogliere mai abbastanza C ++ / CLI abbastanza da poter contribuire.

Per alcuni tipi di librerie software native con esigenze di test molto impegnative, C ++ / CLI / NUnit è l'unica combinazione che soddisferà tutte le esigenze di test unitari mantenendo il codice di test agile e in grado di rispondere alle modifiche. Raccomando al libro xUnit Test Patterns: Refactoring Test Code di andare in questa direzione .