J'ai eu un code qui fonctionnait correctement lorsqu'il a été exécuté lors de tests d'unités standard, mais n'a pas fonctionné lorsqu'il a été compilé dans le pot et a été ajouté à titre de dépendance pour un autre projet.
Ce n'était pas un problème Pour trouver la cause fondamentale et le réparer, mais j'ai commencé à penser comment puis-je tester un artefact JAR fraîchement fait avant de le déployer n'importe où, pour vous assurer qu'il fonctionnera pour les utilisateurs finaux et d'autres projets. J'ai googlé ce sujet pendant plusieurs heures, mais je n'ai même pas trouvé quelque chose près de lui. P>
Peut-être que je suis totalement faux et j'essaie de réaliser quelque chose de bizarre, mais je ne peux pas comprendre une autre façon de vérifier comment vérifier packages compilés et soyez confiant qu'il fonctionnera pour d'autres. p>
Quelques détails sur le projet - Simple Java Bibliothèque avec quelques classes, utilisant Gradle 5.5 en tant que système de construction et Travis-CI en tant qu'outil CI / CD, pour Tester J'utilise testng, mais je peux facilement passer à JUNIT si elle sera requise. P>
Si vous curieux du code, qui ne fonctionnait pas lorsque vous avez été compilé dans le colis, voici la version simplifiée: P>
public String readResourceByURI() throws IOException, URISyntaxException
{
new String(Files.readAllBytes(Paths.get(ClassLoader.getSystemClassLoader().getResource("resource.txt").toURI())));
}
3 Réponses :
in gradle, vous pouvez essayer d'exécuter une tâche de script qui exécutent le code de votre pot. Ou complexe mais sur simple POC, cela fonctionne.
Dans le projet de gradle principal crée un «enfant» de sous-projet.
Ajouter une inforation à ce sujet dans Paramètres.Gradle: Dans Build.Gradle Ajoutez ceci: P> compile files('../build/libs/parent.jar')
Mon fichier JAR n'est pas exécutable, il ne fonctionnera donc pas de cette façon. Je veux juste exécuter des tests d'unité contre le pot compilé.
Essayez peut-être que vous exécutez ce test dans un autre projet de grade qui a une dépendance à votre bocal. De cette façon, vous devez avoir une autre collection de test.
Oui, cela peut certainement être fait, mais il est assez complexe de maintenir - pour chaque projet comme celui-ci, vous devez créer un projet de grade supplémentaire et les lier les plus probablement ensemble. Et aussi où dois-je garder tout mon code de test? Dans ce projet séparé? Quoi qu'il en soit, ce sera ma dernière approche de recours si je ne trouverai plus facilement quelque chose de plus facile. Je suis sûr que cela peut être mis en œuvre plus facilement dans la gradle, je ne peux tout simplement pas le comprendre
Oui, ce serait complexe. Vous pouvez créer un sous-projet. Après avoir construit votre pot principal, vous pouvez le copier comme une dépendance à la sous-projet. La même chose avec le code de test. Après cela exécutez la construction en subprojet.
Je ne pense pas qu'il y ait un bon moyen de détecter ce type de problème dans un test unitaire. C'est le genre de problème qui se trouve normalement dans un test d'intégration.
Si votre artefact / livrable est une bibliothèque, des tests d'intégration n'ont normalement pas de sens. Cependant, vous pourrait passer du temps à créer un exemple d'application ou de test utilisant votre bibliothèque, que vous pouvez ensuite écrire un test d'intégration pour.
Vous auriez besoin de vous demander s'il y a suffisamment d'erreurs potentielles de ce type pour justifier cela:
Peut-être que la réponse pragmatique est de reconnaître que vous ne pouvez pas (ou ne pouvez pas vous permettre de) tester tout.
Cela dit, une approche possible pourrait être de choisir un test de test autonome (emballé comme une application non-Gui Java). Ensuite, demandez à Gradle pour exécuter le test de test en tant que tâche scriptée avec des pots pour votre bibliothèque et les tests de l'unité sur la classe de classe.
Merci pour votre réponse! En fait, votre deuxième point sur la plate-forme OS et / ou les versions Java est exactement la raison pour laquelle je souhaite mettre en œuvre de tels outils de pipeline - CI / CD permettez-nous d'automatiser les tests sur différentes plates-formes et versions et il est assez logique d'automatiser également les tests de livrables à protéger du potentiel. Les problèmes pouvant arriver en raison de l'emballage.
Création d'une application d'échantillon, qui utilisera ma bibliothèque est une solution pour aller, mais je suis curieux, cela peut-il être fait beaucoup plus simple que cela? Les grades sont un outil très puissant, je ne peux tout simplement pas croire qu'il n'est pas possible de jouer d'une manière ou d'une autre avec des pathes de classe et d'injecter un pot compilé comme une dépendance pour les tests d'unité ...
Voir mon dernier paragraphe. Mais j'ai mes doutes que vous pouvez avoir suffisamment de "couverture" supplémentaire pour faire valoir la peine d'exécuter des tests d'unité à partir d'un pot. (Cela ne traite que de ce problème spécifique avec le chargement des ressources.)
Désolé, mais je ne peux pas accepter avec vous. Je ne pense pas que le problème du chargement des ressources est le seul problème qui peut arriver en raison de l'emballage, je peux facilement imaginer des problèmes avec certaines dépendances, qui peuvent être manquants dans le pot, mais existent dans votre parcours de classe pendant le développement et l'exécution des tests. Et une autre chose est que je souhaite faire ce pipeline une par défaut pour mes projets futurs, et comme telles erreurs peuvent se produire au début du projet, je suis prêt à investir quelque temps maintenant pour l'éviter à l'avenir.
Ce seront les mêmes configurations des grades qui déterminent les dépendances dans tous vos environnements TEST / DEV. Je ne pense pas à gérer les tests une seconde fois détecterait les dépendances manquantes ... au-delà de ce que le serveur CI fait déjà.
Pourquoi courir des tests deux fois? Mon idée est d'exécuter une itération des tests, la seule exception est que cela peut être exécuté contre le fichier JAR au lieu de fichiers .Class compilé.
Eh bien ... une itération des tests de manière normale et une deuxième itération de manière particulière. C'est deux. Ou avez-vous l'intention de ne pas exécuter les tests de manière normale? Mais de toute façon, j'ai mes doutes que vous trouverez autre chose que le problème spécifique que vous avez déjà identifié.
Oui, je voulais ne pas exécuter tests la voie "normale", mais exécutez-la contre le fichier JAR. Cela me donnera la même couverture qu'avant + confiance que le pot livrable de JAR ne manquera pas pour les autres. Même si ce problème spécifique est le seul problème qui peut arriver, je veux toujours vous protéger de cela, car a) je peux oublier cela b) quelqu'un d'autre qui n'est pas familier avec ce problème peut le faire.
C'est ce que j'ai proposé:
test {
// Add dependency on jar task, since it will be main target for testing
dependsOn jar
// Rearrange test classpath, add compiled JAR instead of main classes
classpath = project.sourceSets.test.output + configurations.testRuntimeClasspath + files(jar.archiveFile)
useTestNG()
}