Quali pratiche esistono per i test unitari specifici delle impostazioni locali?

16

Recentemente abbiamo scoperto un problema specifico per le impostazioni locali nella nostra applicazione e, mentre è stato facile risolverlo (una volta capito cosa stava succedendo), ha fatto sì che il team stia pensando alle pratiche di testing unitario a questo riguardo.

Vorremmo prendere questi problemi prima, idealmente prima che vengano scoperti da un cliente, e vogliamo proteggerci dal reintrodurre bug specifici per le impostazioni locali in futuro, ma duplicare ogni test unitario in almeno un'altra cultura sembra un sacco di spese generali.

In che modo tu o come vorresti affrontare il test delle unità multi-locale?

    
posta Adam Lear 19.01.2011 - 17:26
fonte

2 risposte

4

Generalmente non è necessario duplicare ogni test unitario. Dovresti identificare ciò che è realmente dipendente dalle impostazioni internazionali (una buona lista di controllo è qui ). Molte cose legate all'internazionalizzazione sono soggette al livello più alto di test, quindi al test unitario.

Se si hanno a che fare con dati di stringhe che possono arrivare in diverse codifiche, allora si può utilizzare "test guidato dai dati", cioè passare i dati in diverse codifiche allo stesso metodo di test. Per Java, TestNG è il più adatto per questo.

Un altro possibile problema è la formattazione e l'analisi della data / ora. La maggior parte delle versioni locali utilizza: per separare gli elementi del tempo, ma ce ne sono alcuni che usano punti e i brasiliani usano hm e s (12h15m30s). Anche questo può essere utilizzato dai dati passati in diverse impostazioni locali - non è necessario testarli tutti.

E la verifica della GUI con impostazioni locali da destra a sinistra non è solitamente oggetto di test delle unità.

La linea di fondo è che è necessario identificare quali dati nei test delle unità sono specifici delle impostazioni internazionali e utilizzare test basati sui dati (fornitori di dati) per fornire questi dati ai test.

    
risposta data 19.01.2011 - 17:58
fonte
3

Ecco alcuni suggerimenti:

  • Sempre sviluppa su una macchina con impostazioni locali diverse dal tuo pubblico di destinazione principale. Ti aiuterà a trovare rapidamente bug relativi a date, valuta e ogni problema di formattazione numerica. Fai lo stesso con il tuo server di build, mettilo in Brasile o in Vietnam (non fisicamente, solo le impostazioni).

  • Utilizza accenti e caratteri speciali nel titolo del test, stringhe, ecc. nei test di unità. Il problema di internazionalizzazione più comune che ottengo con il software che uso (non quelli che sviluppo) è con é ed è o anche ç in francese. Mettili in ogni stringa che usi nei test. Usa una parola comune che usi sempre come brèç©

  • Non dimenticare di usare accenti e grafici speciali nei percorsi . Visual Studio.NET stesso ha ancora molti problemi con quello! Dovresti accedere a creare tali directory e leggere / scrivere da esse nei tuoi test.

  • Se utilizzi Visual Studio .NET, nelle proprietà del progetto, in Analisi del codice , attiva Regole di globalizzazione . I problemi più comuni generano un avviso alla compilazione.

  • Assumi uno straniero nel tuo team.

risposta data 19.01.2011 - 19:28
fonte

Leggi altre domande sui tag