Crear unidad de prueba para el escenario poco probable, y es que vale la pena?

Angelina:

Por debajo de método, es que hay una manera de crear unidad de prueba a causa DatatypeConfigurationException, por lo que puede probar que tiró ConversionException?

Aquí está mi código:

public static XMLGregorianCalendar getXMLGregorianCalendar(final LocalDate localDate) {
    XMLGregorianCalendar xmlGregorianCalendar = null;
    if (localDate != null) {
        final String dateString = localDate.format(yyyMMddFormat);
        try {
            xmlGregorianCalendar = DatatypeFactory.newInstance().newXMLGregorianCalendar(dateString);
        } catch (DatatypeConfigurationException e) {
            throw new ConversionException("Unable to format LocalDate.", e);
        }
    }

    return xmlGregorianCalendar;
}

davidxxx:

Aquí la excepción comprobada es lanzada por javax.xml.datatype.DatatypeFactory.newInstance().
Es un método estático. Lo que no puede burlarse de ella recto.

1) Como alternativa, se podría tratar de encontrar el escenario que podría provocar la excepción a ser resucitado.
Vamonos. La excepción es tirar aquí:

private static <T> T findServiceProvider(final Class<T> type)
        throws DatatypeConfigurationException{
    try {
        return AccessController.doPrivileged(new PrivilegedAction<T>() {
            public T run() {
                final ServiceLoader<T> serviceLoader = ServiceLoader.load(type);
                final Iterator<T> iterator = serviceLoader.iterator();
                if (iterator.hasNext()) {
                    return iterator.next();
                } else {
                    return null;
                }
            }
        });
    } catch(ServiceConfigurationError e) {
        final DatatypeConfigurationException error =
                new DatatypeConfigurationException(
                    "Provider for " + type + " cannot be found", e);
        throw error;
    }
}

Así DatatypeConfigurationExceptionse inicia cuando ServiceConfigurationErrorse lanza y atrapado. Pero ServiceConfigurationErrores un error y no una excepción.
Tratando de simular un error se convierte en poco limpia.

2) Otra alternativa para probarlo: envolver DatatypeFactory.newInstance()en una instancia de su propia clase.
De esta manera se puede burlarse de ella sin dificultad:

public class DataTypeFactoryWrapper { 
   public DatatypeFactory newInstance(){
      return DatatypeFactory.newInstance();
   }
}

Ahora cambiar el código de la siguiente manera:

private DataTypeFactoryWrapper dataTypeFactoryWrapper;

//...
xmlGregorianCalendar = dataTypeFactoryWrapper.newInstance().newXMLGregorianCalendar(dateString);

Ahora se puede burlarse dataTypeFactoryWrapperen su clase de prueba.

3) Última alternativa: no probarlo. Tenga en cuenta, ya que es, que es una Errorenvoltura y Errorson difíciles / difícil de prueba.
Cualquiera que sea el javadoc explica que:

Un error es una subclase de Throwable que indica problemas graves que una aplicación razonable no debe tratar de captura. La mayoría de estos errores son condiciones anormales