Devo utilizzare un framework di test delle unità per convalidare i documenti XML?

Uso C # per deserializzare Documenti XML in classi e test di unità da lì. Faccio questo in aggiunta per verificare il documento XML rispetto al file XSD, e funziona alla grande. Consiglio vivamente questo metodo di convalida di XML.

...I would be using C#...

Esamina XMLUnit per .NET

There are no procedural if/else features that allow me to say, for instance, if Country is USA, then Zipcode cannot be empty.

Per questo, ti consigliamo di utilizzare XQuery. In un precedente datore di lavoro, abbiamo lavorato con moduli governativi e le nuove versioni dovevano essere inviate tramite XML. I "test di modifica" (che includevano cose come zip code cannot be empty for US addresses ) erano espressi come espressioni XQueries e XPath. Poiché molte date utilizzate per la convalida, risulta che un non può essere utilizzato la convalida integrata in .NET (hai bisogno di XPath 2 per le date e non in .NET) e devi usare parser esterni (abbiamo scelto Altova).

Dovresti scrivere alcune classi .NET per eseguire la convalida e quindi verificare il loro comportamento previsto con i test unitari.

Il processo per trovare effettivamente i documenti e convalidarli dovrebbe essere completamente separato (Forse qualche altro set di tipi che usa un FileSystemWatcher su una cartella a cui è possibile accedere). Puntare i tuoi test unitari ai documenti XML che hai bisogno di convalidare è una cattiva idea; non dovresti usare un IDE o un runner di test per gestire la tua attività.

Utilizzare un gestore di eccezioni di alto livello per impedire che un file non valido interrompa il processo. Non c'è nulla di speciale nei framework di testing unitario che li rendono utili nelle normali applicazioni (sono essenzialmente gestori di eccezioni).

Inoltre, come pensi di registrare le eccezioni se userai un framework di test per eseguire il tuo codice?

Non credo che il framework di test unitario ti possa aiutare.

I framework di test delle unità sono stati progettati per risolvere questi problemi:

1. Registra automaticamente i test delle unità.
2. Seleziona quali test eseguire a seconda della riga di comando o di altri argomenti.
3. Semplifica l'inizializzazione e la deinizializzazione ripetute.
4. Segnala i valori utilizzati nelle condizioni non riuscite.

Ora non vedo come qualcuno di quelli ti possa aiutare. Hai una lunga lista di test, che devi applicare al documento, devi eseguire tutti i test, non vuoi inizializzare e deinitializzare separatamente per ogni test e hai bisogno di messaggi che descrivono cosa c'è di sbagliato nel documento, non scarico di alcuni oggetti casuali che hai confrontato per controllare.

Soprattutto questo test di isolamento e il fatto, che i quadri di test unitari non sono generalmente progettati per essere eseguiti su set di dati forniti dall'esterno, probabilmente lo ostacoleranno più di qualsiasi altra cosa possa aiutarti. Perché devi scrivere i test stessi nel linguaggio raw comunque e questo è quasi tutto il lavoro che c'è.

Quindi direi semplicemente scegliere una lingua che conosci, una buona libreria di analisi XML, che ti darà un comodo accesso all'albero dei documenti e basta scrivere una semplice applicazione con quella.

Modifica annuncio: .NET ha un compilatore (gli dai XSD e sputa le definizioni di classe, può andare anche nell'altro modo) per generare la rappresentazione dell'oggetto corrispondente al documento dal suo XSD, che è di gran lunga il metodo più conveniente per accedere agli elementi del documento e verificherà che il documento sia conforme all'XSD come effetto collaterale. Quindi consiglierei di usarlo per leggere il documento. Questo non ha nulla a che fare con il test unitario, naturalmente.

XSD 2.0 ha introdotto asserzioni che funzionano effettivamente come se / allora. Sareste in grado di costruire questo "se il paese è USA, quindi il codice postale non può essere vuoto". Ma in effetti gli mancava davvero.

Sebbene si tratti di un thread precedente, non so se la mia risposta sia ancora pertinente.

Il titolo della tua domanda inizia con "Devo usare ...". "Should" è una parola strong. Dovresti testare, ma se usi un framework di testing unitario o qualcos'altro dipende da molti fattori. puoi utilizzare un framework di test delle unità se è quello con cui ti trovi comodo.

Tuttavia, sembra che tu non stia testando le unità di per sé, e le strutture di testing delle unità sono strongmente ottimizzate per quella particolare nicchia. Potresti voler scegliere un framework di test di accettazione come cetriolo o la struttura del robot o lo specflow. Questi tipi di strumenti ti consentono di esprimere i tuoi test più come requisiti aziendali piuttosto che solo un insieme di input e output.