Dev Faq
8
votes

Pourquoi l'EcLemma Cover n'est-elle pas syncronisée (myClass.class)?

J'utilise EcLemma pour l'analyse de la couverture.

Mon code Java comprend un bloc synchronisé (myClass.class) {}.

Eclemma dit qu'il n'est que partiellement couvert, cependant que j'ai eu un test de l'unité dans lequel un fil a accès et un autre thread est bloqué.

est-il possible d'obtenir une couverture complète de synchronisée à l'aide de l'ECLEMMA?

Puis-je annoter le code d'une certaine manière pour dire à l'EcLemma de donner une couverture complète de cette ligne?

genre Cordialement Roger

0 commentaires

3 Réponses :

7
votes

Je ne suis pas sûr qu'il soit possible d'obtenir une couverture complète, puisque Numéro 2939804 Rapports:

Emma marque toujours synchronisé (..) comme partiellement couvert

Exemples: xxx

peut-être un outil différent ( Comme COBERTURA ) donnerait un résultat différent? (Je n'ai pas testé récemment).

Mise à jour décembre 2012 (plus de 2 ans plus tard):

Nathan D Ryan Rapports :

synchronisé s'allumera sur vert si le bloc synchronisé contient du code qui attend sur un moniteur d'objet et un test interrompt le fil d'attente.

Après une petite expérimentation, j'ai pu obtenir une couverture complète de la ligne Synchronisée si le bloc synchronisé est terminé normalement et complété brusquement en raison d'une exception.

5 commentaires

On dirait que tu as raison. J'ai essayé ceci: synchronisation d'objet = myclass.class; Synchronisé (synchroniser) {} mais cela n'a pas aidé, même si mon test a un fil d'attente et un autre fil d'obtention du mutex.

Dans mon expérience, synchronisé s'allumera sur vert si le bloc synchronisé contient du code qui attend sur un moniteur d'objet et un test interrompt le fil d'attente. Je n'ai jamais pris la peine de creuser dans l'instrumentation EMMA pour déterminer si cela est vrai dans le cas général, cependant.

Après une petite expérimentation, j'ai pu obtenir une couverture complète de la ligne synchronisée si le bloc synchronisé est terminé normalement et terminé brusquement en raison d'une exception.

@ Nathand.ryan intéressant. J'ai inclus votre commentaire dans la réponse pour plus de visibilité.

@Nathanryan pouvez-vous s'il vous plaît partager un exemple?

0
votes

Je crois que le problème est myClass.class qui apparaît apparemment en utilisant

http://emma.sourceforge.net/faq.htm#q .Fractional.Examples

branches implicites dues à une classe cachée.forname (). Ce cas est plutôt malheureux parce que c'est assez courant et pourtant le programmeur n'a presque aucun contrôle sur elle.

parce que la classe.forname () peut jeter des exceptions vérifiées, le compilateur émet un bloc de capteur qui les repousse comme non vérifié. Ce bloc de prise presque jamais exécuté dans la pratique, mais cela réussit à marquer la ligne comme partiellement couvert.

J'ai raté que sur la première lecture.

Je vais essayer de ré-écrire mon code pour obtenir une couverture complète.

/ roger

0 commentaires
1
votes

EcLemma utilise Jacoco en dessous de l'analyse de la couverture.

Comme expliqué dans Jacoco's (actuellement non existant) Option de filtrage Javac.Sync , le comportement est le résultat du code octet généré pour les blocs synchronisés:

Un bloc synchronisé Java est compilé dans deux instructions de Bytecode: Monitorenter au début et à la monitorexit à la fin du bloc.

Pour vous assurer que le moniteur est libéré dans tous les cas, un gestionnaire d'exception est installé qui pointe vers une autre instruction de Monitorexit. Ce bloc de gestionnaire d'exception provoque généralement une couverture de ligne partielle qui n'a pas de sens du point de vue du code source.

un Jacoco Numéro 245 explique comment des exceptions peuvent être déclenchées pour atteindre une couverture complète , si cela devrait être désiré, comme l'a également expliqué par @ Nathan-Ryan:

  1. Un test qui exécute le bloc synchronisé normalement
  2. Un deuxième test qui jette (et attend donc) une exception de l'intérieur du bloc synchronisé.
1 commentaires

(Salut arie). Jacoco ne comprend donc pas que le flux de contrôle est Safe : Si vous atteignez le point d'entrée, vous atteindre le point de sortie. J'imagine qu'un bloc avec des variables locales est compilé dans un bloc qui initialise les habitants, exécute le corps et nettoie les habitants, avec un gestionnaire d'exception implicite supplémentaire enveloppé autour du bloc qui nettoie les habitants en cas d'exception. Cela semble exactement le même style; Pourtant, vous pouvez obtenir une couverture complète sur un bloc en "exécutant". (Notre outil de couverture de test Java instruit sur le code source et ne serait pas confondu).

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject