```
function equals(x, y) {
return x == y;
}
```

How would I know that this property is related to that function:

```
property(
integer(), integer(),
(x, y) => equals(x, y) == equals(y, x),
)
```

Obviously it’s calling the function, but how do we figure out if the call is incidental or an attribute of the function itself. Static analysis is an option, but that can be challenging to build and sequencing the steps would be somewhat complex to orchestrate.

Other languages provide a way to annotate functions and classes, but in the Javascript world the only conversations I can find are around documentation. Javascript is a pretty dynamic language, though, so maybe there’s something clever we can do there. Here’s the property, definition and test reorganized a bit; it doesn’t get us where we want to go, but helps organize things a little differently.

```
const equals_property = property(
integer(), integer(),
(x, y) => equals(x, y) == equals(y, x),
)
function equals(x, y) {
return x == y;
}
test("symmetric", () => {
assert(
equals_property
)
})
```

One possible idea is to use first order functions to wrap function creation in a way that attaches a provide property:

```
function def(property, func) {
func.property = property;
return func;
}
const equals = def(
property(
integer(), integer(),
(x, y) => equals(x, y) == equals(y, x),
),
(x, y) => x == y,
)
test("symmetric", () => {
assert(
equals.property
)
})
```

So then it does seem possible to attach a property directly to the associated function. It might get a little complicated when we begin looking at defining objects like this, but this is enough to demonstrate that it’s possible to establish a direct link between a piece of logic and a property.

]]>```
function equals(x, y) {
return x == y;
}
```

Let’s also take an extremely simple property related to this expression:

```
property(
integer(), integer(),
(x, y) => equals(x, y) == equals(y, x),
)
```

Our goal is to identify some mechanism which can determine that such a property can be inferred in a function calling `equals`

:

```
function double_equals(x, y) {
return equals(2*x, 2*y);
}
```

Building this example, though, I’m beginning to see a counterexample to the original premise. Of course, `double_equals`

retains the symmetry of `equals`

, but something like this wouldn’t:

```
function is_double(x, y) {
return equals(x, 2*y);
}
```

Perhaps there’s a special circumstance when the structure of both arguments are identical, but this feels like it’s diving too heavily into the specifics of mathematics. It’s also possible there’s more advanced things to explore in this area, but I’m looking to tackle something less complex.

So instead of confidentally inferring all properties from lower level abstractions, I’m envisioning a system which can extrapolate candidates properties. It would propose symmentry for both `double_equals`

and `is_double`

, but leave it up to the user to determine its relevance. It also gives the user an opportunity to define a revised version of the property such as this:

```
property(
integer(), integer(),
(x, y) => is_double(x, y) == is_double(y*2, x/2)
)
```

I didn’t achieve what I set out to at the beginning of this article, diving into the practical mechanics of substitution, but I was able to identify a flaw in the original approach. The original idea might eventually be possible, but this revised approach proves to be a much more tractable problem.

]]>I’ll use some simple mathematical properties as a way to explain what I mean. Consider, for example, a property true of the `>`

relationship:

```
property(
integer(), integer(), integer(),
(a, b, c) => (a > b && b > c) ? a > c : true,
)
```

Here’s a simple function that could be built on top of that relationship:

```
function positive(x) {
return x > 0;
}
```

We of course know that, if `j > k`

and `k`

is positive, then `j`

must also be positive. What I’m interesting in determining is if, because I defined the transitive property as a generative test, such a property could be automatically determined.

Before I embark on trying to pry apart the mechanics of how to figure something like that out, though, I need to validate this makes logical sense. To accomplish this, we somehow must infer that `c == 0`

in the original property; perhaps easier said than done, but assuming it is determined leads to the following property:

```
property(
integer(), integer(),
(a, b) => (a > b && b > 0) ? a > 0 : true,
)
```

Then we can transform this again by replacing with the definition of `positive`

:

```
property(
integer(), integer(),
(a, b) => (a > b && positive(b)) ? positive(a) : true,
)
```

These transformations are far from trivial in most languages, but shows it’s at least possible to make logical transformations from base properties to more elaborate ones. This kind of meta-analysis might be more than Javascript is capable of in a practical way, but now I at least know it’s logically possible to reach such conclusions.

]]>First, though, let me talk about what I’m looking to explore. A lot of people talk about how unit testing is a reasonable approximation for proving the correctness of a program, but what’s always sat uncomfortably with me is how easy it is to overlook corner cases. Generative testing offers the potential to more comprehensively cover a piece of code, and I wish to examine how it can be used to more comprehensively cover the contract it fulfills.

A basic property is defined like this:

```
const { check, gen, property } = require('testcheck');
const result = check(
property(
gen.int,
x => x - x === 0
)
)
```

I suppose I could write something to look at that result, but that can be a little clunky when I’m looking to use this frequently. It does offer test framework integration, but because it was last updated 6 years ago it doesn’t support Vitest which appears to be the current front runner.

I can still wrap it in a test with an expectation, though, so still pretty easy to play around with:

```
test("x - x", () => {
const result = check(
property(
gen.int,
x => x - x === 0
)
);
expect(result.result).toBeTruthy();
});
```

Here’s the basic call signature, stripped of specific examples:

```
check(
property(
gen.<type>,
<some function returning a boolean>
),
<options>
)
```

There are a ton of different generators, enough that most conceivable cases would be covered. It’s also possible to construct new generators by composing the ones provided, which gives a reasonable amount of extensibility.

Fast Check appears to be more actively maintained and feature rich, but the documentation isn’t as well organized. The basic usage is pretty much identical:

```
test("x - x == 0", () => {
fc.assert(
fc.property(
fc.integer(),
(x) => x - x == 0
)
)
})
```

Because it’s actively maintained, though, it supports modern testing libraries and so I didn’t have to examine the result to get the test to fail.

This library also seems to provide many generators which can be extended to check most things I could imagine.

The basic footprint of all JS generative testing libraries is the same, although there only appears to be one library actively maintained. Even though it’s not too cumbersome, the footprint in both cases is a bit clunky and leads to a lot of extra code to transition between a simple test and a property based test.

]]>