La autoría de un conjunto de reglas de validación requiere los pasos siguientes :
Si el conjunto de reglas especificado en la sección "Validaciones adicionales" no existe, la infraestructura de pruebas dinámicas generará un conjunto de reglas inicial. El conjunto de reglas inicial tendrá una clase denominada "ValidationResult" con la clase de regla base y un atributo "evidence", como se ha mencionado en la sección Contrato de conjuntos de reglas de validación, y se asociará con la categoría Validación de pruebas dinámicas.
Algunas veces, se especifica un conjunto de reglas existente como el conjunto de reglas que se ha de utilizar para la validación. Generalmente, esto sucede cuando se crea una nueva versión de tipo de pruebas dinámicas y la versión de tipo de pruebas dinámicas anterior ya tenía especificado un conjunto de reglas para la validación. Si se utiliza un conjunto de reglas existente, debe cumplir con el contrato de conjuntos de reglas de validación. Un punto a tener en cuenta es que si se modifica un conjunto de reglas de validación existente, los cambios se verán en todas las versiones de tipo de pruebas dinámicas que han estado utilizando este conjunto de reglas.
Como se ha descrito en la sección sobre la clase de regla DefaultEvidenceValidationResult, esta clase de regla tiene atributos correspondientes a los diferentes conjuntos de validaciones. Todos estos atributos tienen un valor nulo, lo que significa que de forma predeterminada no hay validaciones definidas en ninguno de los conjuntos de validación. Para un tipo de pruebas dinámicas concreto, es posible que sean necesarios todos o solamente algunos de los conjuntos de validación. Por ejemplo: es posible que una versión de tipo de pruebas dinámicas solo requiera "detailsValidations" y "standardValidations". Y, por lo tanto, solo deben volver a definirse los atributos correspondientes a los conjuntos de validación. Generalmente, se utiliza lista fija CER para crear la lista de validaciones en un conjunto.
Normalmente, una validación hará referencia a datos del registro de pruebas de caso o a los registros de pruebas de caso relacionados, es por ello que el contrato para los conjuntos de reglas de validación especifica que deben tener un atributo denominado "evidence". Este atributo se rellena con datos de la instancia de pruebas de caso correspondiente siempre que se invoca el conjunto de reglas.
Se puede definir una validación utilizando la expresión de creación de CER. La expresión de creación, cuando se invoca para la clase de reglas de Validación requiere que se especifique una validación para el atributo isFailure y para el atributo failureMessage.
La derivación para el atributo isFailure debe generar un valor booleano. Por ejemplo, presupongamos que hay dos atributos, "startDate" y "endDate", en un tipo de pruebas dinámicas y que la validación necesaria es que el valor de "startDate" no debe ser el mismo que el valor de "endDate". La derivación para el atributo isFailure de esta validación puede utilizar una expresión de comparación CER que compare los atributos "startDate" y "endDate". La expresión de comparación obtendrá el valor de estos dos atributos utilizando una expresión de referencia en el atributo "evidence" de la clase de reglas de validación.
La derivación del atributo failureMessage debe generar un valor de tipo curam.creole.value.Message. Para ello, la derivación puede utilizar un mensaje XML o una expresión de mensaje de recursos. Una vez más, si el mensaje se ha de parametrizar con los datos del registro de pruebas de caso, se puede acceder al atributo necesario mediante el atributo "evidence" de la clase de reglas de validación utilizando la expresión de referencia.
Opcionalmente, se puede especificar un valor para el "informationalType" de la validación. Si no se especifica ningún valor, se deberá considerar que el tipo informativo es erróneo. No obstante, se pueden utilizar las operaciones estáticas, error(), warning() y fatalError(), de curam.dynamicevidence.validation.impl.InformationalType para especificar un tipo informativo diferente.
Normalmente, el tipo informativo depende de la modalidad de validación. Se puede acceder a la modalidad de validación de una sesión de validación concreta mediante el atributo "validationMode" de la clase de reglas de resultado de validación. A continuación, se puede comparar la modalidad de validación utilizando las operaciones estáticas applyChanges(), approve(), insert(), modify(), validateChanges(), definidas en curam.dynamicevidence.validation.impl.ValidationMode, para determinar el tipo informativo que se ha de utilizar. Por ejemplo, la modalidad de validación de una sesión de validación se puede comparar con "Aplicar cambios" y "Validar cambios" y el tipo informativo se puede especificar como error en el primer caso y como aviso en el último caso.