Hi,

It seems like the HTTP Assert package does not allow me to specify a body to pass in a POST request for example. Looking at the HTTPBody() function, the body argument is set to nil:
req, err := http.NewRequest(method, url+"?"+values.Encode(), nil)

Is this by design, or am I looking at a missing feature?

Cheers,

I'd like an option for shouldEqualJson to ignore keys in actual that are unspecified in expected. It should probably be included for shouldNotEqualJson as well.

I think this could be achieved either by:

• Expanding CompareMode with new modes: CompareMode.StrictIgnoringUnknownKeys and CompareMode.LenientIgnoringUnknownKeys
• Adding a new flag to matcher signatures: `ignoreUnknown

Description

Is there any difference between ContainItemsAssignableTo and AllBeAssignableTo?
Spending five minutes looking at them, they seem to test the same scenario.
(With the exception, that AllBeAssignableTo has special handling for IEnumerable<Type>)

In contrast to other Contain methods, ContainItemsAssignableTo expects all elements to satisfy and not just a subset

Summary

The assertion should verify that the input is neither uppercase nor lowercase.

Example

assertThat("Hello World").isMixedCase();

Feature Request

Description:
API for Date matchers. Some matchers are inspired by Jasmine Matchers.

Possible solution:

Jasmine-like matchers:

expect(date).toBeDate(); // Matcher added
expect(date).toBeValidDate();  // Matcher added

expect(date).toBeAfter(otherDate); // Matcher added
expect(date).toBeBefore(otherDa

Let's dive into the source code:

https://github.com/sindresorhus/is/blob/d528545e02de3396ea900cd93af478292f0697ee/source/index.ts#L184

Only [Symbol.iterator] property is checked, meaning the value is at least Iterable<T>. It may be IterableIterator<T> if the presence of one more property, next, is ensured.

interface Iterable<T> {
    [Symbol.iterator](): Iterator<T>;
}

Location of the documentation

The page doesn't exist yet. A new page titled something like "Importing Other Schema Formats" or something like that.

Note: You can check the latest versions of the docs on master here.

Documentation problem

The frictionless schema support that was added here https://github.com/pandera-dev/pander

As a SDET
I want a documentation or Wiki page where the expected vs actual field matching is explained
So that I can use these in my test automation to test the server response payloads and headers
e.g. id=123 , id="123", isValid=true, isValid="true" etc

AC1:

Cover the following currently supported mechanisms with examples

• $EQ
• (int)
• (float) or (decimal)
• (boolean)

Platform (all, jvm, js): jvm
Extension (none, kotlin 1.3): none

Code related feature

expect(path).notToBeReadable()

//instead of

expect(path).feature { f(it::isReadable) }.toEqual(false)

Following the things you need to do:

logic

• extend PathAssertions with a function isNotReadable (see PathAssertions as a guideline)
• implement isNotReadable in Def

Normally, the "to be truthy" assertion does not take any value as it simply asserts that a subject can be coerced to a boolean true (in the case of "to be falsy" it is coercion to boolean false).

It seems that early on these assertions inherited an optional form where a custom message can be supplied as their argument - this was likely inspired by earlier assertions frameworks (assert on node