los números de cobertura de pruebas unitarias de Java no coinciden

Question

A continuación se muestra una clase que he escrito en una aplicación web que estoy construyendo el uso de Java Google App Engine. He escrito pruebas unitarias utilizando TestNG y pasar todas las pruebas. Luego ejecutar EclEmma en Eclipse para ver la cobertura de las pruebas en mi código. Todas las funciones muestran una cobertura del 100%, pero el archivo en su conjunto está mostrando la cobertura de alrededor del 27%. ¿Dónde está el código descubierto el 73% proviene de?

Puede alguien ayudarme a entender cómo funciona EclEmma y por qué estoy recibiendo la discrepancia en los números?

package com.skaxo.sports.models;

import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;

@PersistenceCapable(identityType= IdentityType.APPLICATION)
public class Account {

    @PrimaryKey
    @Persistent(valueStrategy=IdGeneratorStrategy.IDENTITY)
    private Long id;

    @Persistent
    private String userId;

    @Persistent
    private String firstName;

    @Persistent
    private String lastName;

    @Persistent
    private String email;

    @Persistent
    private boolean termsOfService;

    @Persistent
    private boolean systemEmails;

    public Account() {}

    public Account(String firstName, String lastName, String email) {
        super();
        this.firstName = firstName;
        this.lastName = lastName;
        this.email = email;
    }

    public Account(String userId) {
        super();
        this.userId = userId;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public Long getId() {
        return id;
    }

    public String getUserId() {
        return userId;
    }

    public void setUserId(String userId) {
        this.userId = userId;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    public boolean acceptedTermsOfService() {
        return termsOfService;
    }

    public void setTermsOfService(boolean termsOfService) {
        this.termsOfService = termsOfService;
    }

    public boolean acceptedSystemEmails() {
        return systemEmails;
    }

    public void setSystemEmails(boolean systemEmails) {
        this.systemEmails = systemEmails;
    }
}

A continuación se muestra el código de prueba para la clase anterior.

package com.skaxo.sports.models;

import static org.testng.Assert.assertEquals;
import static org.testng.Assert.assertNotNull;
import static org.testng.Assert.assertTrue;
import static org.testng.Assert.assertFalse;

import org.testng.annotations.BeforeTest;
import org.testng.annotations.Test;

public class AccountTest {

    @Test
    public void testId() {
        Account a = new Account();
        a.setId(1L);
        assertEquals((Long) 1L, a.getId(), "ID");
        a.setId(3L);
        assertNotNull(a.getId(), "The ID is set to null.");
    }

    @Test
    public void testUserId() {
        Account a = new Account();
        a.setUserId("123456ABC");
        assertEquals(a.getUserId(), "123456ABC", "User ID incorrect.");
        a = new Account("123456ABC");
        assertEquals(a.getUserId(), "123456ABC", "User ID incorrect.");
    }

    @Test
    public void testFirstName() {
        Account a = new Account("Test", "User", "test@example.com");
        assertEquals(a.getFirstName(), "Test", 
                "User first name not equal to 'Test'.");
        a.setFirstName("John");
        assertEquals(a.getFirstName(), "John", 
                "User first name not equal to 'John'.");
    }

    @Test
    public void testLastName() {
        Account a = new Account("Test", "User", "test@example.com");
        assertEquals(a.getLastName(), "User",
                "User last name not equal to 'User'.");
        a.setLastName("Doe");
        assertEquals(a.getLastName(), "Doe", 
                "User last name not equal to 'Doe'.");
    }

    @Test
    public void testEmail() {
        Account a = new Account("Test", "User", "test@example.com");
        assertEquals(a.getEmail(), "test@example.com", 
                "User email not equal to 'test@example.com'.");
        a.setEmail("john@example.com");
        assertEquals(a.getEmail(), "john@example.com", 
                "User email not equal to 'john@example.com'.");
    }

    @Test
    public void testAcceptedTermsOfService() {
        Account a = new Account();
        a.setTermsOfService(true);
        assertTrue(a.acceptedTermsOfService(),
                "Accepted Terms of Service not true.");
        a.setTermsOfService(false);
        assertFalse(a.acceptedTermsOfService(),
                "Accepted Terms of Service not false.");
    }

    @Test
    public void testAcceptedSystemEmails() {
        Account a = new Account();
        a.setSystemEmails(true);
        assertTrue(a.acceptedSystemEmails(), "System Emails is not true.");
        a.setSystemEmails(false);
        assertFalse(a.acceptedSystemEmails(), "System Emails is not false.");
    }
}

Answer 1

Esta es una suposición, pero basado en el Javadoc para PersistenceCapable parece que la clase se teje con código adicional por el promotor de JDO para implementar la interfaz. Si este es el caso, es muy posible que el código adicional no está cubierto por las pruebas. Si se quita la anotación y ejecutar las pruebas de nuevo ves la cobertura esperada?

Desde el Javadoc:

  

En la implementación de referencia, el JDO Enhancer modifica la clase para implementar PersistenceCapable antes de cargar la clase en el entorno de ejecución. El reforzador de referencia también añade código para implementar los métodos definidos por PersistenceCapable.

También podría tratar de usar un decompilador como JAD para inspeccionar la clase compilada para verificar si la clase es de hecho tejida con métodos adicionales en tiempo de compilación (o como un proceso de pre). Una vez más desde el Javadoc:

  

Los métodos adicionales en la interfaz PersistenceCapable podrían ser generados por pre-procesar un archivo .java, o pueden ser generados a partir de una herramienta directamente. La técnica exacta para la generación de los métodos adicionales no se especifica por JDO.