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 took me some debugging to find out why my property tests with Koin fail.
I expected KoinListener would reset Koin after each test, no matter if it's a basic test or a property test.

Then I found out that the second run of my simple test reuses the values saved in Koin from the first run.

checkAll<Boolean> { arg -> // true/false
  declareMock {
      Repository(arg)
  }
  get<Ser

Summary

To achieve the most of the fluent api with hasSameHashCodeAs the counterpart doesNotHaveSameHashCodeAs would be nice.

Example

        final Person spiderman = new Person("spiderman");
        final Person otherSpiderman = new Person("spiderman");
        final Person batman = new Person("batman");

        assertThat(spiderman)
            .hasSameHashCod

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

https://pandera.readthedocs.io/en/stable/checks.html

Documentation problem

An important piece of functionality is that ignore_na=True in a Check will drop elements with nulls (for columns) and rows with any nulls (for dataframe checks)

Suggested fix for documentation

Add documentation for this in the user guide so that it's highlighted

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): all
Extension (none, kotlin 1.3): none

Code related feature

Currently, we use groovy in the samples. The Kotlin DSL is still somewhat RC I would say, not everything is smooth but I think it is good enough so that we can already use it in the samples projects

Your first contribution?

• Write a comment I'll work on this if you would like to take this iss

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