Gestion des différences de la base de données locale et distante dans les tests

J'ai un test unitaire en Java qui écrit un horodatage constant dans une ligne dans ma base de données de test locale, le lit et le compare à ce que j'attendais. Cela fonctionne très bien sur mon ordinateur portable local qui est sous le fuseau horaire GMT.Gestion des différences de la base de données locale et distante dans les tests

Lorsque j'engage le code sur notre serveur d'intégration continue, le test échoue avec un temps différent de -5 heures. Ce n'est pas une surprise puisque notre serveur d'intégration est hébergé sur AWS sur la côte Est des États-Unis. Cependant, cela cause un problème ...

À moins de changer mon serveur MySQL local pour avoir le même fuseau horaire que le serveur distant (et avoir tous les développeurs de mon équipe aussi), quelqu'un peut-il me montrer comment résoudre ce problème dans le code sans devenir trop hacky?

//Fetch actual table contents 
IDataSet databaseDataSet = databaseTester.getConnection().createDataSet(); 
ITable actualTable = databaseDataSet.getTable("batch"); 

// Load expected data from an XML dataset 
IDataSet expectedDataSet = new XmlDataSet(getClass().getResourceAsStream("/dbunit/expected_insert_batch.xml")); 
ITable expectedTable = expectedDataSet.getTable("batch"); 

// Assert actual database table match expected table 
Assertion.assertEquals(expectedTable, actualTable);

Merci,

Source

2010-12-14 Scruffers

Vous devez détailler comment vous comparez les horodatages, en tant qu'entier? en tant que chaînes? – Guillaume

Oui, affichez les détails du test unitaire s'il vous plaît :) –

La comparaison d'horodatage est effectuée par DBUnit – Scruffers

Vous pouvez set a timezone pour le serveur MySQL distinct du fuseau horaire du système d'exploitation, ou même pour des sessions individuelles de DB. Le premier est préférable à l'OMI, tout comme UTC partout sauf pour l'interface utilisateur et lors de l'importation de données.

Source

2010-12-14 11:57:57

Je vous suggère de faire en sorte que tous vos systèmes utilisent le même fuseau horaire, par ex. UTC/GMT + 0 et utilisez uniquement le fuseau horaire lors de l'affichage à un utilisateur ou dans les rapports.

Source

2010-12-14 12:00:16

Si vous créez l'horodatage en Java, je recommande d'utiliser un simulacre afin qu'il ne dépende pas du tout du système.

Voir les réponses à this question pour des idées.

Source

2010-12-14 12:03:12

Mais mon test d'unité teste que le DAO écrit correctement dans la base de données. J'écris déjà un horodatage constant grâce à un simulacre, mais le problème est qu'il doit être écrit via le DB pour tester - et si le fuseau horaire est différent comme décrit il provoque un problème ... – Scruffers

Pour ce problème, je ' d avocat comme d'autres ont répondu, il suffit de garder toutes les heures de la base de données en UTC et d'utiliser le fuseau horaire pour l'affichage seulement. –

OK, cela peut ne pas être la meilleure option, mais pourquoi ne pas créer une autre

"/dbunit/expected_insert_batch.xml"

pour votre serveur CI. Puis ajoutez un interrupteur dans votre test d'unité pour le fuseau horaire.

Source

2010-12-14 12:46:25

-1

Vous devez faire en sorte que votre test ne dépende pas de l'environnement. Cherchez des endroits où vous pouvez rendre ce champ dynamique et cela devrait fonctionner n'importe où.

Source

2010-12-14 14:37:36

Un test DAO dépendra toujours de la base de données sur laquelle il s'exécute, mais je suis d'accord dans les tests généraux devrait être agnostique de l'environnement. – Scruffers

Gestion des différences de la base de données locale et distante dans les tests

Répondre

Questions connexes