A Kotlin library that verifies if an object meets a specification
refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.
A Specification<Subject, Violation> is an interface and implementors should implement the isMetBy method
fun isMetBy(subject: Subject): Report<Violation>an element of type Subject is the subject under test and Report<Violation> serves as a report about if the subject under test successfully adheres to the specification.
Report<Violation> is a sealed class having two subclasses: Success and Failure. The Failure constructor accepts a list of Violations that can inform the client why the subject under test does not adhere to the specification.
We would like to use the specifikation library to validate objects as follows. Let's say we have created a Specification<Person, String> and a candidate Person object.
val report: Report<String> = specification.isMetBy(person)
when (report) {
is Success { /* person passed specification */ }
is Failure { violations = report.violations }
}The specifikation library is not the only Kotlin library that can validate if an object meets a specification. We are at least aware of, and have examined the following libraries.
These are all great libraries. Unfortunately neither of these libraries fitted our needs. That in part was the motivation for creating this library, even though we are familiar with xkcd:927.
Below you will find some of the reasons above libraries do not fit our needs.
The initial impetus to create konform
building a kind of generator to transform a limit subset of a JSON Schema code to Konform later. Therefore I started with implementing validations that are like what can be found there.
Rules that are outside of JSON Schema code have limited support. Although it is possible to add custom rules, it involves a setting up a bit of boilerplate.
Rules in kalidation are subclasses of a sealed class ConstraintRule. There is no way to add a custom rule to kalidation, other than testing a function on the object under test.
This robs us the oppertunity to specify rules specific to our domain.
An object not meeting a specification is not exceptional to us. We receive objects in bulk, over the wire, from various sources. If a violation would be signaled by an exception, processing the collection would be difficult.
valiktor throws an ConstraintViolationException when an object does not meet a specification. Therefore it is not a nice fit.